diff --git a/text/0000-sbom.md b/text/0000-sbom.md index 106a28d62..9e18c78bc 100644 --- a/text/0000-sbom.md +++ b/text/0000-sbom.md @@ -81,11 +81,9 @@ sbom = ["CycloneDX"] This information can be displayed on the registry and `pack inspect-buildpack`. -The lifecycle of the respective `bom` files during rebuilds would be exactly the same as the `bom` table currently. +The `lifecycle` binaries would be responsible for taking all of the above `bom` files, and copying them in `/layers/config/sbom////bom.` for the layer `bom` files where `type` could be `build` or `launch`. Buildpack level BOM files will reside at `/layers/config/sbom///bom.` where the type could be `launch` and `build` respectively. -The lifecycle would be responsible for taking all of the above `bom` files, and putting them in `/layers/config/sbom///.bom.` for the layer `bom` files where `type` call be `build` or `launch` or `both`. Buildpack level BOM files will reside at `/layers/config/sbom//build.bom.` and `/layers/config/sbom//launch.bom.` for the `launch` and `build` `bom` respectively. - -Additionally the lifecycle will be responsible for creating merged `bom` files, merging `bom` formats of the same type and outputting them at `/layers/config/sbom/build.bom.` or `/layers/config/sbom/launch.bom.` respectively. Initially this will only be supported for CycloneDX as it has a well defined and efficient way of merging multiple `bom` files. A reference implementation can be found at the [`cyclonedx-cli`](https://github.com/CycloneDX/cyclonedx-cli) project. In the future we may add support for merging SPDX `bom` files as well. +Additionally the `lifecycle` binaries will be responsible for creating merged `bom` files, merging `bom` formats of the same type and outputting them at `/layers/config//sbom/bom.`. Initially this will only be supported for CycloneDX as it has a well defined and efficient way of merging multiple `bom` files. A reference implementation can be found at the [`cyclonedx-cli`](https://github.com/CycloneDX/cyclonedx-cli) project. In the future we may add support for merging SPDX `bom` files as well. Merging different formats (CycloneDX/SPDX/Legacy CNB format) is a non-goal and will not be supported. Since we will be making the individual `bom` files available as well, if users/platforms wish, they can choose to write conversion and merging logic but this will not be supported in the lifecycle. @@ -95,22 +93,20 @@ Since we will be preserving the original output files and if a buildpack chooses # How it Works [how-it-works]: #how-it-works -The lifecycle would be responsible for reading, merging and restoring the appropriate `bom` files (the legacy CNB format and the CycloneDX format currently). The lifecycle of these `bom` files would be tied to their respective 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. +The `lifecycle` binaries would be responsible for reading, merging and restoring the appropriate `bom` files (the legacy CNB format and the CycloneDX format currently). The lifecycle of these `bom` files would be tied to their respective 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 CycloneDX `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 - +For merging the CycloneDX `bom` files, the `lifecycle` binaries 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` binaries 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.layer.name` (Optional) - Set to the name of the layer if the `bom` was associated with a specific layer. -The lifecycle will put all the `build` related entries in the `/layers/config/sbom/build.bom.cdx.json` file and `launch` entries in `/layers/config/sbom/launch.bom.cdx.json` - -The output `bom` files could be uploaded to the registry following a format as proposed in https://github.com/sigstore/cosign/pull/439 +The `lifecycle` binaries will put the `bom` files from layers set to `launch = true` inside the `/layers/config/sbom/launch///bom.` hierarchy otherwise it will put them in `/layers/config/sbom/build///bom.`. -which looks like - +## BOM Restoration -![](https://user-images.githubusercontent.com/1714486/125960784-2795510d-511f-40fb-91f2-f9f97eeb573b.png) +During the export phase, the `lifecycle` binaries would be responsible for putting all the `/layers/config/sbom/launch/` directory in the application image as a separate layer and storing its diffIDs in a label for restoring launch layer `bom` files during a rebuild. During a rebuild, it will use previous app image to restore the layer level `launch bom` files. -This will however be better defined in a subsequent RFC. +For non-launch layers, it can just store the files alongside the layer itself and the lifecycle of these `bom` files will be tied to the layer cache lifecycle itself. The `/layers/config/sbom/build/` directory will be an ephemeral directory that is only used during a single build as a convenient place to store all the `build` `bom`s for the platform to export out and make available to the users if needed. # Backwards compatibility @@ -137,7 +133,6 @@ Only use one SBOM format like `CycloneDX` or `SPDX` and bake it into the lifecyc [unresolved-questions]: #unresolved-questions - Interactions with the stack SBOM and how to represent that and merge it with the Buildpack SBOM. -- Restore/export logic for SBOM files. This will be covered in a subsequent RFC. # Spec. Changes (OPTIONAL) [spec-changes]: #spec-changes