Our SBOMs should reference the base image's SBOMs

[mattmoor]

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

ExternalDocumentRef:DocumentRef-kubernetes-v1.23.5 https://sbom.k8s.io/v1.23.5/source SHA1: c7c35638348a5c2cf6d3af72cfdc94a66e33252b

I think the work here would be:

1. Detect whether our base image has an SBOM, and if so
2. Encode some sort of ExternalDocumentRef into our image-level SBOMs.

cc @jdolitsky @imjasonh @jonjohnsonjr

[mattmoor]

Here was the K8s SBOM he pointed me at: https://sbom.k8s.io/v1.23.5/release

[mattmoor]

He also mentioned:

and that reference is used in other places to describe that the artifacts were produced from a package in it:

Relationship: SPDXRef-Package-k8s.gcr.io-kube-controller-manager-amd64-v1.23.5 GENERATED_FROM DocumentRef-kubernetes-v1.23.5:SPDXRef-Package-kubernetes

[mattmoor]

Once chainguard-dev/apko#149 lands (+releases) it would be nice to start on this, so that images based on ghcr.io/distroless/static can take advantage.

@puerco any thoughts on the form of this syntax to target for a base image?

[imjasonh]

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.

[mattmoor]

I think @puerco wants to chase this a bit.

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Keep fresh with the 'lifecycle/frozen' label.

[mattmoor]

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/ ghcr.io/distroless/static.

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 DESCRIBES the image/index, vs. the Go binary, so perhaps this is just a new "relationship" between the image/index package and the base image? WDYT @puerco?

[puerco]

Yes! This is something I been wanting to build for a long time in bom. There is of course the problem of linking to the doc but we can add the base image as a package as mentioned in this comment and have them referenced something like this:

SBOM 1 - ko image
======================
package - ko_image 
  \ package - binary layer 
     \ file - binary
     \ file - kodata1
     \ file - kodata
  \ package base_image (purl: oci://YYYY)

SBOM 2 - Base image (apko example, arch image)   
====================================
package base_image (purl: oci://YYYY)
  \ package os_layer
     \ package apk1
     \ package apk2
     \ package apk3

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.

[mattmoor]

@puerco is this a correct list of SPDX relationship types? https://cloud.google.com/container-analysis/docs/reference/rest/v1beta1/RelationshipType

DESCENDANT_OF seems perfect for base images.