Create and bundle spdx and cyclonedx json SBOMs as part of stemcell creation

[rthill91]

• Install syft in image via Dockerfile
• Add new sbom_create stage to generate sbom.spdx.json as part of stemcell creation
• Bundle sbom.spdx.json into resulting stemcell tgz
• Bundle sbom.cdx.json into resulting stemcell tgz

[ragaskar]

I agree w/ @rkoster that there should be some provision for checking the provenance of the install script/installed libraries.

I can also share that in our experience, we've seen issues with tracking latest syft in that new features are added very quickly and occasionally these new features have undesirable impacts (e.g., we've seen new cataloguers suddenly introduce records for dozens of libraries that -- in our case -- were all false positives). It might be nice to have a way to easily pin syft when necessary. It's possible there is some implementation overlap with provenance for version pinning, so perhaps it makes sense to take that on now.

[ragaskar]

also, thanks for this contribution, cool stuff!

[beyhan]

What is the estimated size of the generated SBOM? Have you also tried the other formats supported like the cycloneDX and the syft own format?

[rthill91]

What is the estimated size of the generated SBOM? Have you also tried the other formats supported like the cycloneDX and the syft own format?

~34M in my jammy fips test build from today.

As for other formats, minimal consideration was given beyond the desire for something generic and machine readable. That put syft format out. Beyond that, internally spdx is the chosen format.

[VinodAnandan]

@rthill91 Could you please consider adding support for CycloneDX format as well?

[rkoster]

Our internal tooling uses CycloneDX, so supporting both formats would be a plus for us. The cyclonedx-json output format seems to be supported by syft. But this is not a blocker for me and could be done by someone else in a later PR. I just want to make sure the discussion about supporting multiple formats is captured here.

[rthill91]

Our internal tooling uses CycloneDX, so supporting both formats would be a plus for us. The cyclonedx-json output format seems to be supported by syft. But this is not a blocker for me and could be done by someone else in a later PR. I just want to make sure the discussion about supporting multiple formats is captured here.

syft definitely supports cyclonedx. The only complexity (off the top of my head) to adding support is that it makes it turns sbom generation into a configurable option rather than a static thing and it'll make the expected files in the output tgz configurable. I could just change the sbom to sbom.json to avoid that last bit, but I like the clarity of specifying that it's spdx, particularly if there's support for other formats included.

I don't mind working this, but it'll likely have to wait a few weeks (Noble release is going to keep me busy) and I'd rather it be a separate PR.

[rkoster]

I would not make it an optional build flag, but instead just include both sboms, similar to what buildpacks are doing: https://github.com/buildpacks/rfcs/blob/main/text/0095-sbom.md#what-it-is

So we would end up with something like:

expected = ['stemcell.MF', 'packages.txt', 'dev_tools_file_list.txt', 'image', 'sbom.spdx.json', 'sbom.cdx.json']

[rthill91]

I would not make it an optional build flag, but instead just include both sboms, similar to what buildpacks are doing: https://github.com/buildpacks/rfcs/blob/main/text/0095-sbom.md#what-it-is

So we would end up with something like:

expected = ['stemcell.MF', 'packages.txt', 'dev_tools_file_list.txt', 'image', 'sbom.spdx.json', 'sbom.cdx.json']

including both makes this a trivial change. I have it staged locally but I'm seeing some test failures (going through the non-iaas-kernel tests rather than aws specific kernel). I'll have to look at this a bit later

[rthill91]

updated to generate cyclonedx and spdx sboms

[rthill91]

updated title/description to reflect the addition of cdx sbom

[rkoster]

Thanks! @rthill91