-
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
Add run image SBOM #186
base: main
Are you sure you want to change the base?
Add run image SBOM #186
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,76 @@ | ||
# Meta | ||
[meta]: #meta | ||
- Name: Run Image Structured SBOM | ||
- Start Date: 2021-10-25 | ||
- Author(s): aemengo | ||
- Status: Draft <!-- Acceptable values: Draft, Approved, On Hold, Superseded --> | ||
- RFC Pull Request: (leave blank) | ||
- CNB Pull Request: (leave blank) | ||
- CNB Issue: (leave blank) | ||
- Supersedes: (put "N/A" unless this replaces an existing RFC, then link to that RFC) | ||
|
||
# Summary | ||
[summary]: #summary | ||
|
||
This RFC proposes the following - | ||
|
||
- A run image can contain a single layer holding an SBOM (in format of CycloneDX or SPDX or Syft) of installed packages at `/cnb/sbom/bom.<ext>.json`, where `<ext>` will be `cdx` for CycloneDX documents, `spdx` for SPDX documents, and `syft` for Syft documents. These will initially be the only 3 supported SBOM types. | ||
- The diffID of this layer is written as a `LABEL` on the corresponding run image with the key: `io.buildpacks.base.sbom`. | ||
- For the sake of parity, the diffID of buildpack SBOM layers (created by lifecycle) is written as a `LABEL` on the corresponding run image with the key: `io.buildpacks.app.sbom`. | ||
|
||
# Definitions | ||
[definitions]: #definitions | ||
|
||
- SBOM (Software Bill Of Materials) / BOM: A list of components in a piece of software. Software vendors often create products by assembling open source and commercial software components. The SBOM describes the components in a product. In case of buildpacks the SBOM describes the contents of the various layers, buildpacks, stacks and the output app container. | ||
- Run Image: A container image that serves as a base image for application images in the buildpack toolchain. | ||
|
||
# Motivation | ||
[motivation]: #motivation | ||
|
||
This RFC serves as an addendum to [#RFC 95: SBOM](https://github.com/buildpacks/rfcs/blob/main/text/0095-sbom.md) which introduces the SBOM for buildpack installed packages. For a full depiction of packages within a container image, container scanning tools would _also_ need an SBOM of the installed OS packages. These multiple SBOM files would be merged as part of the lifecycle build process, for easy consumption by an automated scanning tool. | ||
|
||
# What it is | ||
[what-it-is]: #what-it-is | ||
|
||
A stack creator is permitted to specify a SBOM for a given run image, in one discrete layer, at the following file path: | ||
|
||
```shell | ||
/cnb/sbom | ||
└── bom.<ext>.json | ||
aemengo marked this conversation as resolved.
Show resolved
Hide resolved
|
||
``` | ||
|
||
And a label with key of `io.buildpacks.base.sbom`, and value of the diffID of this layer, stored as metadata on the run image. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we also add the condition here that this must be the last layer on the image for the lifecycle to consider it a valid sbom? This is to prevent further extensions from re-using the same sbom. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please clarify. How would other extensions use an SBOM depending on the layer order? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @aemengo I meant something like the following - let's say someone takes the above base run image with the SBOm and label+diffid and extends it as FROM valid-run-image-with-sbom
USER root
RUN apt-get install my-package This new image will still have the above specified SBOM and label with the appropriate diffid of the SBOM layer, but the SBOM will be incorrect/stale. With my proposal, the above extension will cause other layers to be added after the SBOM layer which might be a good way to indicate to the lifecycle that the SBOM is potentially stale since the layer with the SBOM diffid won't be the last layer anymore. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
@samj1912 If we go this route maybe we can loosen this a little to be SHOULD? I think a warning might be sufficient here. Also, I am not sure what "must" would imply here. Would the build/rebase fail? Would the lifecycle remove the io.buildpacks.base.sbom` entirely. |
||
|
||
With this label specified, the rebase operation can be augmented to reference the new sBOM layer for the intended application image. | ||
|
||
Merging BOM files, whether files of the same format or files of different formats, is out of scope for this RFC. It would require its own separate RFC. | ||
|
||
## Tooling | ||
|
||
To facilitate adherence to this specification, the CNB project will create tooling that consumes a given run container image and a given SBOM json file, to create a new image with the SBOM information embedded at the correct location and diffID metadata attached. This allows for generation of SBOM files both within the image and outside it. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this inteneded to be separate tooling or a part of Once we know which sub-team is responsible I think it's fine to punt the details of the interface to a sub-team specific RFC but it would be good to align generally about who this RFC is handing the baton to. |
||
|
||
# Drawbacks | ||
[drawbacks]: #drawbacks | ||
|
||
This RFC tries to thrust a paradigm which is an even greater burden on stack operators, in light of the recently approved [#RFC 96: Remove Stacks](https://github.com/buildpacks/rfcs/blob/main/text/0096-remove-stacks-mixins.md). | ||
|
||
# Alternatives | ||
[alternatives]: #alternatives | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. A Label is one alternative albeit an unappealing one b/c of the containerd label size issue. An annotation is another alternative. The drawbacks to an annotation are consistency with buildpack-generated SBOM and the impossibility of doing something sensible in the daemon case. |
||
- | ||
|
||
# Prior Art | ||
[prior-art]: #prior-art | ||
|
||
- [#RFC 95: SBOM](https://github.com/buildpacks/rfcs/blob/main/text/0095-sbom.md) | ||
|
||
# Unresolved Questions | ||
[unresolved-questions]: #unresolved-questions | ||
|
||
- | ||
|
||
# Spec. Changes (OPTIONAL) | ||
[spec-changes]: #spec-changes | ||
|
||
- The [platform.md#run-image](https://github.com/buildpacks/spec/blob/main/platform.md#run-image) would need an addition for the `io.buildpacks.base.sbom` key, referencing the layer diffID that holds the run-image BOM. | ||
- The [platform.md#labels](https://github.com/buildpacks/spec/blob/main/platform.md#labels) would need an addition for the `io.buildpacks.app.sbom` key, referencing the app image layer diffID that holds the buildpack BOM. |
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.
In the future, we may want to add a flag to lifecycle to include build-time SBoMs in the app image. We could use labels like
io.buildpacks.build.base.sbom
andio.buildpacks.build.app.sbom
.I don't think this means we should rename
io.buildpacks.base.sbom
toio.buildpacks.launch.base.sbom
-- just thought it might be worth pointing this out.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.
Yes, we may. I personally find it hard to base decisions purely on what may happen. I'd be curious if others explicitly have this use-case.