Add implementation details

Author: sambhav

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 `<layer>.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 `<layer>.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 <image-name> --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