Allow platforms to provide run image sboms

[natalieparellano]

Readable

[buildpack-bot]

Maintainers,

As you review this RFC please queue up issues to be created using the following commands:

/queue-issue <repo> "<title>" [labels]...
/unqueue-issue <uid>

Issues

(none)

[jromero]

Wasn't there an alternative discussed where we would leave it up to the platform to determine the method of attaching an sbom? For instance, if our platform want to use more of an associative artifact (similar to cosign) we could do that. It seems like this RFC only proposes one of what I see possibly being many ways for platforms to want to add this feature. Would it be better if we spec'd out the possible options and a way for further tools to be able to discover how the run image sbom is attached to the app image?

For example, some label that states a) "it's this layer here", or b) "it's located at this URI".

[natalieparellano]

I think there are two problems to solve here - one is how to attach or associate an SBOM with the run image. The other is how to attach or associate a run image SBOM with a CNB-built app image. This RFC is essentially saying we shouldn't worry about the first issue. As for the second issue, this RFC proposes staying consistent with the pattern introduced in https://github.com/buildpacks/rfcs/blob/main/text/0095-sbom.md and put the run image sbom somewhere in /layers/sbom.

[fg-j]

Related to buildpacks/lifecycle#828, these media types need to be accepted with parameters (e.g. version) so that end users / buildpack authors can maintain stronger contracts about the schema versions of the SBOMs that come out of builds.

[natalieparellano]

Thinking about how buildpacks "declare" the media types they support, in buildpack.toml - would we want to do the same for the run image? For example, to put a label on the final app image alerting vulnerability scanners which formats are supported. We could put the supported types in a label on the run image. We'd need to take care during rebase that the label is still accurate.

[natalieparellano]

Added in latest commit - but since we'd be deriving the media type from the file extension, I'm not sure how to derive the parameter. Could we have more flexible file names? Could the platform provide the media type as a separate argument?

[jromero]

Great improvements. Overall I've bought into the idea. The only outstanding items I care about would be the final locations for the sbom on disk and the label name.

[jromero]

Should this section be filled in?

[natalieparellano]

Suggestion: there should be criteria for what gets included in the io.buildpacks.lifecycle.metadata label.

[natalieparellano]

Takeaways from today’s discussion:

Run Image SBOM

We want base images for CNB builds to be as “unspecial” as possible. Allowing run image authors to in any way “bake” an SBOM into the run image should be discouraged. Platforms should use an industry standard method of associating a run image with an SBOM.

For buildpack-provided SBOMs, there is a clear need to include the SBOM files in the application image, for the purpose of restoring the SBOM files on the next build. There is less of a need to do this for run image SBOMs… however…

We do like including the run image SBOM in the application image at a specified location.

Regarding Dockerfiles

Giving extensions the ability to output SBOM files during the “generate” phase is only useful in the narrow case where a Dockerfile is downloading an artifact from the internet (that isn’t known by scanners) and for which the SBOM is known. In this case, the Dockerfile could generate an SBOM file at some location that could be picked up by scanners. This should be part of the genpkgs interface, not the extensions interface.

When Dockerfiles are applied, the lifecycle will know if a new extended run image has been created, or if the run image was switched by a Dockerfile that simply provides a FROM instruction to reference a new base image. In the former case, the lifecycle will run genpkgs. In the latter case, the lifecycle will return the run image reference to the platform, and it will be the platform’s responsibility to locate the run image SBOM.

We will provide tooling to make the process of looking up the run image SBOM as easy as possible.

[natalieparellano]

Platforms should use an industry standard method of associating a run image with an SBOM.

There is less of a need to [include SBOM files in the application image] for run image SBOMs…

We do like including the run image SBOM in the application image at a specified location.

This part doesn't sit very well with me. I feel like, if we're telling platforms "follow industry standards" then it makes sense to use the same standard for ALL images in a pipeline (run image, application image, etc.). It feels weird that there would be this special way to scan buildpacks-produced images when other practices are being adopted at different points in the process.

This makes me think that we should just bite the bullet and say that we'll support multiple ways to associate SOBMs: in-toto attestation, cosign attachment, or (if nothing can be found) we'll just run genpkgs and output a file alongside report.toml.

WDYT @ekcasey @samj1912 @sclevine

[natalieparellano]

Circling back on this - the consensus from 4/7 Working Group seems to be:

• While it's convenient to have the run image SBOM in the image (so that the complete SBOM can be constructed if the attached SBOM is ever lost)
• This adds a fair bit of complexity, especially with respect to rebase

Therefore, the suggestion above is preferred:

we should just bite the bullet and say that we'll support multiple ways to associate SOBMs: in-toto attestation, cosign attachment, or (if nothing can be found) we'll just run genpkgs and output a file alongside report.toml

Probably the most fruitful path forward would be to work out some of the complexities as part of the Dockerfiles POC and then open another RFC describing the genpkgs component and the platform's use of it. I'll put this RFC in draft for now.

[natalieparellano]

Cross post from other thread: buildpacks/spec#298 (comment)

Closing this in favor of #195.