Add sbom restoration description

Signed-off-by: Sambhav Kothari <[email protected]>

Author: sambhav

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/<type>/<buildpack-id>/<layer-id>/bom.<ext>` for the layer `bom` files where `type` could be `build` or `launch`. Buildpack level BOM files will reside at `/layers/config/sbom/<type>/<buildpack-id>/bom.<ext>` 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/<buildpack-id>/<layer-id>/<type>.bom.<ext>` for the layer `bom` files where `type` call be `build` or `launch` or `both`. Buildpack level BOM files will reside at `/layers/config/sbom/<buildpack-id>/build.bom.<ext>` and `/layers/config/sbom/<buildpack-id>/launch.bom.<ext>` 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.<ext>` or `/layers/config/sbom/launch.bom.<ext>` 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/<type>/sbom/bom.<ext>`. 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/<buildpack-id>/<layer-id>/bom.<ext>` hierarchy otherwise it will put them in `/layers/config/sbom/build/<buildpack-id>/<layer-id>/bom.<ext>`.
 
-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