-
Notifications
You must be signed in to change notification settings - Fork 170
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve SBOM storage/format #3068
Comments
Currently Zarf has prioritized an agnostic format for SBOMs to capture the maximum amount of data that Syft (the tool Zarf uses under the hood) can give Zarf. The Syft JSON files can be downconverted to other formats and conversion is covered in the latter half of this docs section: https://docs.zarf.dev/ref/sboms/#extracting-a-packages-sbom |
For the tooling/version used are you looking to see Zarf or Syft? As of v0.41.0, the Syft json has |
Thanks guys, the Syft JSON makes sense. I'm sold.
I think I'd expect to see Syft, but maybe this is not so important afterall. I'm still looking into it but maybe all that matters is the schema version. I need to see if different
I see these fields, but Zarf is failing to populate Another thing I discovered today is that Zarf is not preserving the original manifest digests in the generated SBOM. Here is the diff between the |
This is good to know thanks for doing this analysis. The media types changing makes sense. I'm not sure why syft writes the mediatypes of layers in that format, even when the manifest in the registry is already using the newer Losing the architecture, manifest and manifest digests is a bit concerning though. The differences likely have to do with the fact that we're using the equivalent of |
@AustinAbro321 something we're wrestling with on the sec-hub implementation is what to do when multiple Zarf packages include the same container images, but with slightly different SBOMs. We're noticing that A good example is comparing these two SBOMs between
I thought that this was the result of bumping the syft dependency, but it turns out both packages were built using the same Zarf version ( tl;dr: I think this is all good evidence suggesting we should store SBOMs as attestations and not bundle them with the Zarf package. We should be periodically rescanning packages so we can provide richer SBOMs (more metadata, up-to-date |
Describe what should be investigated or refactored
Currently the
sboms.tar
layer contains both JSON documents and generated HTML for an "SBOM viewer" page for each of the images in the Zarf package. The current approach has several downsides:For comparison, compressed tarballs that contain only the JSON documents are <10x the size:
Proposed solution
adopt standard SPDX JSON formatThe text was updated successfully, but these errors were encountered: