-
Notifications
You must be signed in to change notification settings - Fork 71
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
Allow platforms to provide run image sboms #211
Conversation
Maintainers, As you review this RFC please queue up issues to be created using the following commands:
Issues(none) |
66ec9d5
to
49cc1f0
Compare
…n sbom for the run image Signed-off-by: Natalie Arellano <narellano@vmware.com>
49cc1f0
to
f40a237
Compare
Signed-off-by: Natalie Arellano <narellano@vmware.com>
Signed-off-by: Natalie Arellano <narellano@vmware.com>
Why should we *not* do this? Leaving the location of the run image sbom unspec'd could make it harder for logic-less platforms like Tekton to use the creator. However, a CNB-provided "prepare" operation ([currently under discussion](https://github.com/buildpacks/rfcs/pull/202)) could make this easier. For example, a preparer could look for a run image sbom in a file, attestation, attachment, or layer (picking the first one it finds) and provide the data as a file to the creator. The Tekton task that uses the creator currently already has a ["prepare" step](https://github.com/tektoncd/catalog/blob/4bf8b57aa105f0c7ce05fc122a11b1b0d5822fcd/task/buildpacks/0.3/buildpacks.yaml#L70-L121) which could be modified to invoke a preparer binary. | ||
|
||
# Alternatives | ||
[alternatives]: #alternatives |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
.
text/0000-run-image-sbom.md
Outdated
The accepted media types would be: | ||
* `application/vnd.cyclonedx+json` with ext `cdx.json` | ||
* `application/spdx+json` with ext `spdx.json` | ||
* `application/vnd.syft+json` with ext `syft.json` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
Signed-off-by: Natalie Arellano <narellano@vmware.com>
Signed-off-by: Natalie Arellano <narellano@vmware.com>
Signed-off-by: Natalie Arellano <narellano@vmware.com>
Signed-off-by: Natalie Arellano <narellano@vmware.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
- The existence or behavior of a preparer binary that knows how to download run image sboms. | ||
|
||
# Spec. Changes (OPTIONAL) | ||
[spec-changes]: #spec-changes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this section be filled in?
Signed-off-by: Natalie Arellano <narellano@vmware.com>
Signed-off-by: Natalie Arellano <narellano@vmware.com>
Signed-off-by: Natalie Arellano <narellano@vmware.com>
text/0000-run-image-sbom.md
Outdated
|
||
## Buildpack-provided SBOMs | ||
|
||
SBOM files output by buildpacks are currently exported in `/layers/sbom/launch/<buildpack id>`. The layer containing the buildpack-provided SBOM files is referenced in the `io.buildpacks.lifecycle.metadata` label with key `sbom`. For parity with `io.buildpacks.base.sbom`, a `io.buildpacks.app.sbom` label will also be added. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggestion: there should be criteria for what gets included in the io.buildpacks.lifecycle.metadata
label.
Signed-off-by: Natalie Arellano <narellano@vmware.com>
Signed-off-by: Natalie Arellano <narellano@vmware.com>
Takeaways from today’s discussion: Run Image SBOMWe 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 DockerfilesGiving 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. |
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 |
Circling back on this - the consensus from 4/7 Working Group seems to be:
Therefore, the suggestion above is preferred:
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 |
Cross post from other thread: buildpacks/spec#298 (comment) Closing this in favor of #195. |
Readable