Skip to content
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

Closed
wants to merge 12 commits into from

Conversation

natalieparellano
Copy link
Member

@natalieparellano natalieparellano commented Mar 10, 2022

@buildpack-bot
Copy link
Member

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)

@natalieparellano natalieparellano force-pushed the npa/run-image-sbom branch 2 times, most recently from 66ec9d5 to 49cc1f0 Compare March 10, 2022 17:36
…n sbom for the run image

Signed-off-by: Natalie Arellano <[email protected]>
@natalieparellano natalieparellano marked this pull request as ready for review March 10, 2022 17:43
@natalieparellano natalieparellano requested a review from a team as a code owner March 10, 2022 17:43
Signed-off-by: Natalie Arellano <[email protected]>
Signed-off-by: Natalie Arellano <[email protected]>
text/0000-run-image-sbom.md Outdated Show resolved Hide resolved
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
Copy link
Member

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".

Copy link
Member Author

@natalieparellano natalieparellano Mar 24, 2022

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 Show resolved Hide resolved
text/0000-run-image-sbom.md Outdated Show resolved Hide resolved
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`
Copy link

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.

Copy link
Member Author

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.

Copy link
Member Author

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 <[email protected]>
@nebhale nebhale self-requested a review March 30, 2022 18:25
Copy link
Member

@jromero jromero left a 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
Copy link
Member

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?


## 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.
Copy link
Member Author

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 <[email protected]>
@natalieparellano
Copy link
Member Author

natalieparellano commented Mar 31, 2022

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
Copy link
Member Author

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
Copy link
Member Author

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 natalieparellano marked this pull request as draft April 12, 2022 18:44
@natalieparellano
Copy link
Member Author

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

Closing this in favor of #195.

@sambhav sambhav deleted the npa/run-image-sbom branch April 15, 2022 21:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants