Add alternatives and comparison references

Signed-off-by: Sambhav Kothari <skothari44@bloomberg.net>

text/0000-sbom.md

@@ -2,7 +2,7 @@
 [meta]: #meta
 - Name: Structured SBOMs
 - Start Date: 2021-06-02
-- Author(s): [@samj1912](https://github.com/samj1912)
+- Author(s): [@samj1912](https://github.com/samj1912), [@sophiewigmore](https://github.com/sophiewigmore), [@ForestEckhardt](https://github.com/ForestEckhardt)
 - RFC Pull Request: (leave blank)
 - CNB Pull Request: (leave blank)
 - CNB Issue: (leave blank)
@@ -14,7 +14,7 @@
 This RFC proposes the following - 
 
 - Use of CycloneDX as the SBOM storage format.
-- Moving the SBOM from a label to a file in a separate layer.
+- 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
@@ -53,46 +53,54 @@ Having a structured and consistent SBOM that can be consumed by downstream syste
 ## What is the expected outcome?
 
 - Use of CycloneDX as the SBOM storage format and updates the the specification and lifecycle to reflect the same.
-- Moving the SBOM from a label to a file in a separate layer.
+- 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
 
 Currently the SBOM is defined in the `<layer>.toml`, `launch.toml` and `build.toml` respectively under the `[bom]` table.
-It may not be the most user-friendly way for buildpack authors to create SBOM documents in the above format. This RFC proposes that the `bom` be moved to `<layer>.bom.<ext>`, `launch.bom.<ext>` and `build.bom.<ext>` instead where `<ext>` may be `xml` or `json`. This is mostly to allow for different BOM generation tools to be used. This also allows us in the future to add support for `spdx`  tag documents or other file formats if needed.
+It may not be the most user-friendly way for buildpack authors to create SBOM documents in the above format. This RFC proposes that the `bom` be moved to `<layer>.bom.<ext>`, `launch.bom.<ext>` and `build.bom.<ext>` instead where `<ext>` will be `cdx.json`
 
 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 and storing it in `/layers/config/sbom.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`.
+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`.
 
 # How it Works
 [how-it-works]: #how-it-works
 
-This is the technical portion of the RFC, where you explain the design in sufficient detail.
-
-The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work.
+TODO
 
 # Drawbacks
 [drawbacks]: #drawbacks
 
-Why should we *not* do this?
+This RFC adds a fair bit of complexity to the lifecycle and makes it responsible for more than just buildpack orchestration and container/layer assembly.
 
 # Alternatives
 [alternatives]: #alternatives
 
-- What other designs have been considered?
-- Why is this proposal the best?
-- What is the impact of not doing this?
+## Use a different SBOM format (SPDX)
+
+SPDX is the other leading SBOM format. It is a Linux Foundation project and is another front-runner in the SBOM eco-system. SPDX is heavily focused on compliance related metadata whereas CycloneDX is focused on security and supply chain analysis. SPDX also doesn't have as rich of an ecosystem when it comes to tooling for generating SBOMs as CycloneDX.
+
+For reference see - https://cyclonedx.org/tool-center/
+
+A more complete analysis of leading SPDX and CycloneDX tooling relevant to Buildpacks is documented at [sophiewigmore/bom](https://github.com/sophiewigmore/bom). This includes common SBOM field mapping, example SBOM outputs, scanning times.
+
+## Delegate SBOM merging to platform
+
+The main reason that the lifecycle needs to have a hard dependency on CycloneDX in this proposal is because we propose that the lifecycle merges the SBOM from various buildpacks and layers. If the lifecycle were to not do this, the content of the SBOM can be completely opaque to the lifecycle. This might provide greater flexibility and almost no dependency on the lifecycle side. Instead a platform like `pack` can be responsible for gathering the individual SBOM files and merging them together for the user. This can also be provided as a reusable library/CLI so that other platforms could do the same.
+
 
 # Prior Art
 [prior-art]: #prior-art
 
-Discuss prior art, both the good and bad.
+- [#RFC 53](https://github.com/buildpacks/rfcs/blob/main/text/0053-decouple-buildpack-plan-and-bom.md)
+- [#RFC 87](https://github.com/buildpacks/rfcs/blob/main/text/0087-bom-in-layer-metadata.md)
 
 # Unresolved Questions
 [unresolved-questions]: #unresolved-questions