-
Notifications
You must be signed in to change notification settings - Fork 389
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
Our SBOMs should reference the base image's SBOMs #654
Comments
Here was the K8s SBOM he pointed me at: https://sbom.k8s.io/v1.23.5/release |
He also mentioned:
|
Once chainguard-dev/apko#149 lands (+releases) it would be nice to start on this, so that images based on @puerco any thoughts on the form of this syntax to target for a base image? |
The cosign repo has a spec for specifying layered SBOMs: https://github.com/sigstore/cosign/blob/main/specs/SBOM_SPEC.md#scopes I'm not sure if anybody actually adheres to it today, either on the producing- or consuming-side. If we decide not to follow that advice we should probably advocate to have it removed as a recommendation, just to limit the proliferation of unimplemented or half-implemented specs in the world. |
I think @puerco wants to chase this a bit. |
This issue is stale because it has been open for 90 days with no |
In #743 I pass the image/index into the functions generating SBOMs, and we can access the OCI annotations we populate on those (if present, ahem docker ahem 👀 ), which may be good enough, especially as we switch to an OCI default base image w/ If folks are cool with that (@imjasonh @jonjohnsonjr ) then I think we just need to understand how to encode this relationship in the SBOM. Another thing I did in #743 was make it so that the SBOM |
Yes! This is something I been wanting to build for a long time in
By splitting them into two independent SBOMs we avoid the problem of finding a direct link to the SBOM that needs to be available when parsing it. |
@puerco is this a correct list of SPDX relationship types? https://cloud.google.com/container-analysis/docs/reference/rest/v1beta1/RelationshipType
|
Found this as well: https://spdx.github.io/spdx-spec/v2-draft/relationships-between-SPDX-elements/ |
I also noticed |
Yes the list in gcp seems to be from the spdx spec. |
#744 should do this for SPDX |
Currently our SBOMs only capture the contents of the Go binary we overlay on the base image, but it should be possible to (at least) discover the SBOM for the base image, or capture its contents.
I believe the prevailing wisdom (from @puerco) is to reference the base image's SBOM, and there is some precedent for "external references" in SBOMs such as this "external reference" from the K8s SBOMs
I think the work here would be:
ExternalDocumentRef
into our image-level SBOMs.cc @jdolitsky @imjasonh @jonjohnsonjr
The text was updated successfully, but these errors were encountered: