gistfile1.txt

sam:palm_tree: May 12th at 6:54 AM
@steering-committee (tagging you as this might result in a significant change across a wide set of buildpacks) / @tooling-maintainers - We have been using paketo buildpacks based off packit with sbom support for a while now and I had a couple of pieces of feedback around separation of the SBOM generation tooling from the packit logic
Currently each packit based buildpack imports the entirety of syft. This means that almost all of these buildpacks with the recent version of syft will also import large chunks of dependencies (related to cosign) which hamper development on these buildpacks and dependency management with them (it pulls in all sorts of k8s related deps) and also increases the buildpack size (went from 2mb to 5.5mb) for EVERY buildpack using packit. This is a fairly significant increase to the overall builder if you account for duplicates due to meta buildpacks.
The strong coupling with syft also means that whenever there are breaking changes with syft, we must first update packit and then each and every buildpack using packit. This also means that if an end user wants a slightly custom version of syft (to improve or change the sbom output) it becomes a non trivial task.
Going the Java buildpacks route for sbom implementation seems more sustainable as it allows us to swap in a different sbom buildpack and we can change and update the sbom behavior for an entire class of buildpacks. This can allow users to use a specific version of the sbom buildpacks, without updating to the latest version of their language buildpack.
I would be happy to write out the above points and more compelling arguments for a shift in paradigm WRT sbom generation process in packit as an RFC but just wanted to float the pain points that we have faced trying to use and customize this interface. Happy to hear how your feedback has been around this. (edited) 
19 replies


Daniel Mikusa  28 days ago
I will say that the downside of the route we've chosen with the Java buildpacks is flexibility. The Syft format is anything but stable, they have frequent new major versions for their schema. Some affect the output we're generating, some do not. Regardless, we just have to accept whatever output the syft CLI gives us because there are no cli options to control the specific schema of Syft JSON that's generated.
If you're using CycloneDX as the output format, this is less so, however there was a schema change there as well not too long ago and again the syft CLI doesn't give you the ability to fix the schema version.
I understand that the route that Packit has taken allows for a more customized output, which seems like a distinct advantage in terms of offering stable, predictable output in the SBOM format.


sam:palm_tree:  28 days ago
You can still have flexibility if you have the sbom buildpack separated out. You can create an alt version of the syft CLI. That way the only interface you have to conform to is the syft CLI interface, not the syft library interface.


sam:palm_tree:  28 days ago
That way you can inject custom login and keep all that contained in one binary (the “syft” like binary)


sam:palm_tree:  28 days ago
this is what we do


Daniel Mikusa  28 days ago
Yes, I was having a similar thought. Is that something you have code for at the moment? I think we could pretty easily expand the syft buildpack to provide different syft binaries. We'd discussed doing this to allow the selection of certain fixed versions of syft, like to lock in before different major schema changes. Something like this would be better though, if there were an alternative cli that allowed one to select the given schema.


sam:palm_tree:  28 days ago
we do - but it is currently all internal


sam:palm_tree:  28 days ago
happy to discuss our current system and how it works


sam:palm_tree:  28 days ago
I don’t see a lot of benefit in contributing back our specific binary since it has some custom sbom generation/transformation logic


sam:palm_tree:  28 days ago
but we can contribute back the interfaces we use on top of libpak


sam:palm_tree:  28 days ago
and how this whole system works


sam:palm_tree:  28 days ago
it will also help solve the issue Paketo has with syft being a moving target


sam:palm_tree:  28 days ago
(this is also why we have this system internally so that we can easily sub out any sbom generation logic from one unified place independently of the build logic)


Daniel Mikusa  28 days ago
That would be fantastic. Maybe a zoom, when you have some time? I'd want to see if @Emily Casey is interested in joining too.
:+1:
1



Emily Casey  28 days ago
I broadly agree with this and have a preference for the flexibility of the buildpack-contributred CLI approach. However, I am leery of depending on a fork of the CLI in the long term. I would want to work with the syft folks to ensure that changes we make there are things that could be successfully contributed upstream eventually.
Also, I think @banana is an important person to include in this discussion, given he has been in the weeds with the packit implementation and has some thoughtful takes on the topic.


Daniel Mikusa  28 days ago
Yes, it'll be a little bit but it would probably make sense to wait until @banana is back. There's no reason to rush any of this.


sam:palm_tree:  28 days ago
Definitely, we can try and make changes to Syft to make it more extensible. I was not necessarily thinking about forking it. But more along the lines of importing it as a library in a separate executable which we can wrap, control or extend.


sam:palm_tree:  28 days ago
And this executable is installed by a sbom generator buildpack which the subsequent buildpacks use


sam:palm_tree:  27 days ago
if y’all are at Kubecon - we can also chat in person :wink:
:+1:
1



fgj:spiral_calendar_pad:  21 days ago
I’ve been mulling this over lately. I wonder if it’d be helpful if the Syft-dependent portions of packit were split into a separate package. Then Paketo buildpacks could inject our Syft wrapper  into our buildpack implementations, and folks (like Bloomberg) can continue to use Paketo buildpacks as libraries and inject their own alternate SBOM implementations in the buildpacks.
This preserves the current non-Java buildpacks’ ability to generate SBOMs for the layers that they own (e.g. the go-build buildpack generates an SBOM for the modules compiled into the binary it builds), but also frees up consumers of packit and Paketo buildpacks to swap in whatever SBOM implementation they choose, without the bloat of packit depending on syft. If users prefer to delegate SBOM generation to a separate buildpack, they can inject a no-op SBOM generator into the other buildpacks.
This could be as simple as moving the current packit/sbom package into a separate repository.