diff --git a/text/0000-sbom.md b/text/0000-sbom.md index f676a7857..5f08e57bb 100644 --- a/text/0000-sbom.md +++ b/text/0000-sbom.md @@ -15,7 +15,6 @@ This RFC proposes the following - - Use of CycloneDX as the SBOM storage format. - Moving the SBOM from `.toml`, `launch.toml` and `build.toml` to a separate file. -- Enhancements to the platform spec and pack to allow easy interaction with SBOMs including conversion between major SBOM formats. # Definitions [definitions]: #definitions @@ -54,7 +53,6 @@ Having a structured and consistent SBOM that can be consumed by downstream syste - Use of CycloneDX as the SBOM storage format and updates the the specification and lifecycle to reflect the same. - Moving the SBOM from `.toml`, `launch.toml` and `build.toml` to a separate file. -- Enhancements to the platform spec and `pack` to allow easy interaction with SBOMs including conversion between major SBOM formats. # What it is [what-it-is]: #what-it-is @@ -66,14 +64,16 @@ The above bom documents need to be created in CycloneDX format. The lifecycle of the respective `bom` files during rebuilds would be exactly the same as the `bom` table currently. -The lifecycle would be responsible for taking all of the above `bom` files, merging it while tagging it with the originating layer or buildpack the `bom` came from and storing it in `/layers/config/sbom.cdx.json`. This file would also be stored in a layer of its own and the lifecycle would be responsible for storing the layer digest in a label `io.buildpacks.bom.digest`. - -Platforms like `pack` would be responsible for fetching the `bom` from the above layer and displaying it to the user in a format of their choice via something like `pack inspect-image --bom --format=spdx_2_2`. +The lifecycle would be responsible for taking all of the above `bom` files, merging it while tagging it with the originating layer or buildpack the `bom` came from and storing it in `/layers/config/bom.cdx.json`. # How it Works [how-it-works]: #how-it-works -TODO +The lifecycle would be responsible for reading, merging and restoring the appropriate `bom` files. The lifecycle of these `bom` files would be tied to their respectice metadata `toml` files. See [RFC 0087](https://github.com/buildpacks/rfcs/blob/main/text/0087-bom-in-layer-metadata.md#how-it-works) for more details. For merging the `bom` files, the lifecycle could replicate or use tooling from [CycloneDX-cli](https://github.com/CycloneDX/cyclonedx-cli) which has a merge operation. The only additional piece of information that the lifecycle would inject are `CycloneDX` [`metadata`](https://cyclonedx.org/use-cases/#properties--name-value-store) the following property keys - + +`io.buildpacks.bom.buildpack.id` - Buildpack ID for the buildpack that created the BOM +`io.buildpacks.bom.type` - Set to `build` or `launch` as applicable. +`io.buildpacks.bom.layer.name` (Optional) - Set to the name of the layer if the `bom` was associated with a specific layer. # Drawbacks [drawbacks]: #drawbacks @@ -105,15 +105,14 @@ The main reason that the lifecycle needs to have a hard dependency on CycloneDX # Unresolved Questions [unresolved-questions]: #unresolved-questions -- What parts of the design do you expect to be resolved before this gets merged? -- What parts of the design do you expect to be resolved through implementation of the feature? -- What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC? +- Implementation details about how the lifecycle should be merging the SBOMs. +- Moving the SBOM from the `io.buildpacks.build.metadata` label to a file in the output image to avoid large labels +- Interactions with the stack SBOM and how to represent that and merge it with the Buildpack SBOM. # Spec. Changes (OPTIONAL) [spec-changes]: #spec-changes -Does this RFC entail any proposed changes to the core specifications or extensions? If so, please document changes here. -Examples of a spec. change might be new lifecycle flags, new `buildpack.toml` fields, new fields in the buildpackage label, etc. -This section is not intended to be binding, but as discussion of an RFC unfolds, if spec changes are necessary, they should be documented here. + +Yes, see above. # References