From b81398992a22aea44977df0f7da9164bcc4bc416 Mon Sep 17 00:00:00 2001 From: Sambhav Kothari Date: Wed, 2 Jun 2021 19:55:49 +0100 Subject: [PATCH 01/11] Add initial draft Signed-off-by: Sambhav Kothari --- text/0000-sbom.md | 118 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 118 insertions(+) create mode 100644 text/0000-sbom.md diff --git a/text/0000-sbom.md b/text/0000-sbom.md new file mode 100644 index 000000000..a76c3e555 --- /dev/null +++ b/text/0000-sbom.md @@ -0,0 +1,118 @@ +# Meta +[meta]: #meta +- Name: Structured SBOMs +- Start Date: 2021-06-02 +- Author(s): [@samj1912](https://github.com/samj1912) +- RFC Pull Request: (leave blank) +- CNB Pull Request: (leave blank) +- CNB Issue: (leave blank) +- Supersedes: (put "N/A" unless this replaces an existing RFC, then link to that RFC) + +# Summary +[summary]: #summary + +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. +- Enhancements to the platform spec and pack to allow easy interaction with SBOMs including conversion between major SBOM formats. + +# Definitions +[definitions]: #definitions + +- SBOM/BOM: A software bill of materials (SBOM) is a list of components in a piece of software. Software vendors often create products by assembling open source and commercial software components. The SBOM describes the components in a product. In case of buildpacks the SBOM describes the contents of the various layers, buildpacks, stacks and the output app container. +- CycloneDX: CycloneDX is a lightweight software bill of materials (SBOM) standard designed for use in application security contexts and supply chain component analysis. +- SPDX: Software Package Data Exchange (SPDX) is a file format used to document information on the software licenses under which a given piece of computer software is distributed. +- SWID: SWID is a formal industry standard used by various commercial software publishers designed with software inventory and entitlements management in mind. + +# Motivation +[motivation]: #motivation + +## Why should we do this? + +Quoting [NTIA Whitepaper][NTIA-WP] - +> Modern software systems involve increasingly complex and dynamic supply chains. Unfortunately, the composition and functionality of these systems lacks transparency; this contributes substantially to cybersecurity risks, alongside the cost of development, procurement, and maintenance. This has broad implications in our interconnected world; risk and cost affect collective goods, like public safety and national security, in addition to the products and services upon which businesses rely. +> We propose that increased supply chain transparency through SBOMs can reduce cybersecurity risks and overall costs by: +> - Enhancing the identification of vulnerable systems and the root cause of incidents +> - Reducing unplanned and unproductive work +> - Supporting more informed market differentiation and component selection +> - Reducing duplication of effort by standardizing formats across multiple sectors +> - Identifying suspicious or counterfeit software components + +Currently since container images built by Cloud Native Buildpacks don't follow a generic file system layout, they may not be easily scannable by container scanning tools. We do however provide a BOM which should greatly help sidestep the entire manual scanning process and speed up things like CVE detection by directly providing the CVE scanner with a BOM. + +However, since we currently do not impose any standard for what the BOM should look like and since the metadata table in BOM is a freeform table, it is very hard to have consistent BOMs that can be used by CVE scanners. + +Having a structured and consistent SBOM that can be consumed by downstream systems could greatly enhance the security proposition around buildpacks. + +## What use cases does it support? + +- Consistent SBOM across buildpacks +- Improved integration with other supply chain analysis and scanning tools + +## 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. +- 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 `.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 `.bom.`, `launch.bom.` and `build.bom.` instead where `` 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. + +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`. + +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`. + +# 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. + +# Drawbacks +[drawbacks]: #drawbacks + +Why should we *not* do this? + +# Alternatives +[alternatives]: #alternatives + +- What other designs have been considered? +- Why is this proposal the best? +- What is the impact of not doing this? + +# Prior Art +[prior-art]: #prior-art + +Discuss prior art, both the good and bad. + +# 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? + +# 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. + +# References + +The above RFC was inspired by [NTIA SBOM Formats and Standards Whitepaper - VERSION 202104XX][NTIA-WP] and borrows heavily from it for definitions and references. + + +[NTIA-WP]: https://docs.google.com/document/d/1KEMRrjbMd6FV7-ZFCk-AVVi-QY7qRiYiylxFFUc5Y_8/edit# +[CDX]: https://cyclonedx.org/ +[SPDX]: https://spdx.dev/ +[SWID]: https://nvd.nist.gov/products/swid \ No newline at end of file From 69c9323df9f5aaec44287d0f7f1651f00faf80af Mon Sep 17 00:00:00 2001 From: Sambhav Kothari Date: Thu, 17 Jun 2021 14:11:17 +0100 Subject: [PATCH 02/11] Add alternatives and comparison references Signed-off-by: Sambhav Kothari --- text/0000-sbom.md | 34 +++++++++++++++++++++------------- 1 file changed, 21 insertions(+), 13 deletions(-) diff --git a/text/0000-sbom.md b/text/0000-sbom.md index a76c3e555..f676a7857 100644 --- a/text/0000-sbom.md +++ b/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 `.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 `.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 `.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 `.bom.`, `launch.bom.` and `build.bom.` instead where `` 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 `.bom.`, `launch.bom.` and `build.bom.` instead where `` 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 --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 From bd0ffd64f360ba7c45c781d2134888c25356871b Mon Sep 17 00:00:00 2001 From: Sambhav Kothari Date: Thu, 1 Jul 2021 09:20:25 +0100 Subject: [PATCH 03/11] Add implementation details Signed-off-by: Sambhav Kothari --- text/0000-sbom.md | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/text/0000-sbom.md b/text/0000-sbom.md index f676a7857..f9332398f 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.types` - Set to a comma seperated list of `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 From 98959a9363060ea0bc0e5da9e3b3f69ec6176433 Mon Sep 17 00:00:00 2001 From: Sambhav Kothari Date: Thu, 15 Jul 2021 13:50:56 +0100 Subject: [PATCH 04/11] Add section on backwards compat Signed-off-by: Sambhav Kothari --- text/0000-sbom.md | 63 ++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 59 insertions(+), 4 deletions(-) diff --git a/text/0000-sbom.md b/text/0000-sbom.md index f9332398f..f63f84a58 100644 --- a/text/0000-sbom.md +++ b/text/0000-sbom.md @@ -14,7 +14,7 @@ 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. +- Moving the SBOM from `.toml`, `launch.toml` and `build.toml` to separate files. # Definitions [definitions]: #definitions @@ -52,7 +52,7 @@ 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 `.toml`, `launch.toml` and `build.toml` to a separate file. +- Moving the SBOM from `.toml`, `launch.toml` and `build.toml` to separate files. # What it is [what-it-is]: #what-it-is @@ -64,7 +64,7 @@ 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/bom.cdx.json`. +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/build.bom.cdx.json` and `/layers/config/launch.bom.cdx.json` respectively for `build` and `launch` boms. # How it Works [how-it-works]: #how-it-works @@ -72,9 +72,64 @@ The lifecycle would be responsible for taking all of the above `bom` files, merg 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.types` - Set to a comma seperated list of `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. +Thw lifecycle will put all the `build` related entries in the `/layers/config/build.bom.cdx.json` file and `launch` entries in `/layers/config/launch.bom.cdx.json` + +# Backwards compatibility + +For `BOM` from older buildpacks the following mappings will be defined. Each `BOM` entry will be added as a `CycloneDX` component in the final components list. + +For eg. if we have the BOM table like below - + +```toml +[[bom]] +name = "example" +[bom.metadata] +version = "0.2.3" +foo = "bar" +foo_array = ["bar"] +[[bom]] +name = "example2" +[bom.metadata] +version = "0.0.1" +foo = "bar" +``` + +It will be converted to - + +```json +{ + "bomFormat": "CycloneDX", + "specVersion": "1.3", + "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79", + "version": 1, + "components": [ + { + "type": "library", + "name": "example", + "version": "0.2.3", + "metadata": { + "foo": "bar", + "foo_array": ["bar"] + } + }, + { + "type": "library", + "name": "example2", + "version": "0.0.1", + "metadata": { + "foo": "bar", + } + }, + ] +} +``` + +Since `CycloneDX v1.3` does not define a `metadata` key inside the `component` type, we can simply put the existing `metadata` table inside the `metadata` key in a `component` and use the `loose` JSON schema for `CycloneDX 1.3`. + +The `version` key inside the `metadata` table will be handled as a unique case and will be moved to a top level `version` key inside the `CycloneDX` component. + # Drawbacks [drawbacks]: #drawbacks From 0bea16280e9c2ab0ec1a2b19f62347ffa9a978fa Mon Sep 17 00:00:00 2001 From: Sambhav Kothari Date: Thu, 22 Jul 2021 13:12:44 +0100 Subject: [PATCH 05/11] Add support for multiple sbom formats Signed-off-by: Sambhav Kothari --- text/0000-sbom.md | 88 ++++++++--------------------------------------- 1 file changed, 14 insertions(+), 74 deletions(-) diff --git a/text/0000-sbom.md b/text/0000-sbom.md index f63f84a58..dc8e93f6f 100644 --- a/text/0000-sbom.md +++ b/text/0000-sbom.md @@ -13,7 +13,7 @@ This RFC proposes the following - -- Use of CycloneDX as the SBOM storage format. +- Use of CycloneDX and SPDX as the SBOM storage format. - Moving the SBOM from `.toml`, `launch.toml` and `build.toml` to separate files. # Definitions @@ -51,84 +51,35 @@ 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. +- Use of CycloneDX and SPDX 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 separate files. # What it is [what-it-is]: #what-it-is Currently the SBOM is defined in the `.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 `.bom.`, `launch.bom.` and `build.bom.` instead where `` will be `cdx.json` - -The above bom documents need to be created in CycloneDX format. +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 `.bom.`, `launch.bom.` and `build.bom.` instead where `` will be `cdx.json` for CycloneDX documents and `spdx.json` for SPDX documents. 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/build.bom.cdx.json` and `/layers/config/launch.bom.cdx.json` respectively for `build` and `launch` boms. +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 a stack author may choose to provide a `/cnb/image/merge-bom` binary in the base-image that takes in the above `/layers/config/sbom` folder as its input alongside the location of the final merged `build.bom.` and `launch.bom.`. The `merge-bom` binary can read as input the `/layers/config/sbom` to merge the build and launch `bom` as it sees fit and output them to a combined `build.bom.` and `launch.bom.`. The lifecycle will be responsible for invoking the `merge-bom` binary if it finds one, otherwise it will skip generating the merged bom. # How it Works [how-it-works]: #how-it-works -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 - +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 will simply call out the `merge-bom` binary with the appropriate inputs if one is provided, otherwise it will skip generating them. -- `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 output `bom` files could be uploaded to the registry following a format as proposed in https://github.com/sigstore/cosign/pull/439 -Thw lifecycle will put all the `build` related entries in the `/layers/config/build.bom.cdx.json` file and `launch` entries in `/layers/config/launch.bom.cdx.json` +which looks like - + +![](https://user-images.githubusercontent.com/1714486/125960784-2795510d-511f-40fb-91f2-f9f97eeb573b.png) # Backwards compatibility -For `BOM` from older buildpacks the following mappings will be defined. Each `BOM` entry will be added as a `CycloneDX` component in the final components list. - -For eg. if we have the BOM table like below - - -```toml -[[bom]] -name = "example" -[bom.metadata] -version = "0.2.3" -foo = "bar" -foo_array = ["bar"] -[[bom]] -name = "example2" -[bom.metadata] -version = "0.0.1" -foo = "bar" -``` - -It will be converted to - - -```json -{ - "bomFormat": "CycloneDX", - "specVersion": "1.3", - "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79", - "version": 1, - "components": [ - { - "type": "library", - "name": "example", - "version": "0.2.3", - "metadata": { - "foo": "bar", - "foo_array": ["bar"] - } - }, - { - "type": "library", - "name": "example2", - "version": "0.0.1", - "metadata": { - "foo": "bar", - } - }, - ] -} -``` - -Since `CycloneDX v1.3` does not define a `metadata` key inside the `component` type, we can simply put the existing `metadata` table inside the `metadata` key in a `component` and use the `loose` JSON schema for `CycloneDX 1.3`. - -The `version` key inside the `metadata` table will be handled as a unique case and will be moved to a top level `version` key inside the `CycloneDX` component. +TODO # Drawbacks [drawbacks]: #drawbacks @@ -138,17 +89,7 @@ This RFC adds a fair bit of complexity to the lifecycle and makes it responsible # Alternatives [alternatives]: #alternatives -## 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. +Only use one SBOM format like `CycloneDX` or `SPDX` and bake it into the lifecycle. # Prior Art @@ -160,9 +101,8 @@ The main reason that the lifecycle needs to have a hard dependency on CycloneDX # Unresolved Questions [unresolved-questions]: #unresolved-questions -- 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. +- If the project will be responsible for providing some reference implementation of `merge-bom`. If yes, should it support `CycloneDX` as its first format? # Spec. Changes (OPTIONAL) [spec-changes]: #spec-changes From fd3a8f91ba83668e16a4be02c94f3df3c09da3f0 Mon Sep 17 00:00:00 2001 From: Sambhav Kothari Date: Thu, 29 Jul 2021 12:01:54 +0100 Subject: [PATCH 06/11] Apply suggestions from code review Co-authored-by: Emily Casey Co-authored-by: Yael Harel <43007598+yaelharel@users.noreply.github.com> Signed-off-by: Sambhav Kothari --- text/0000-sbom.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/text/0000-sbom.md b/text/0000-sbom.md index dc8e93f6f..0784f1e9f 100644 --- a/text/0000-sbom.md +++ b/text/0000-sbom.md @@ -6,7 +6,7 @@ - RFC Pull Request: (leave blank) - CNB Pull Request: (leave blank) - CNB Issue: (leave blank) -- Supersedes: (put "N/A" unless this replaces an existing RFC, then link to that RFC) +- Supersedes: [RFC 0087](https://github.com/buildpacks/rfcs/blob/main/text/0087-bom-in-layer-metadata.md), [RFC 0053](https://github.com/buildpacks/rfcs/blob/main/text/0053-decouple-buildpack-plan-and-bom.md) # Summary [summary]: #summary @@ -19,10 +19,10 @@ This RFC proposes the following - # Definitions [definitions]: #definitions -- SBOM/BOM: A software bill of materials (SBOM) is a list of components in a piece of software. Software vendors often create products by assembling open source and commercial software components. The SBOM describes the components in a product. In case of buildpacks the SBOM describes the contents of the various layers, buildpacks, stacks and the output app container. -- CycloneDX: CycloneDX is a lightweight software bill of materials (SBOM) standard designed for use in application security contexts and supply chain component analysis. -- SPDX: Software Package Data Exchange (SPDX) is a file format used to document information on the software licenses under which a given piece of computer software is distributed. -- SWID: SWID is a formal industry standard used by various commercial software publishers designed with software inventory and entitlements management in mind. +- SBOM (Software Bill Of Materials) / BOM: A list of components in a piece of software. Software vendors often create products by assembling open source and commercial software components. The SBOM describes the components in a product. In case of buildpacks the SBOM describes the contents of the various layers, buildpacks, stacks and the output app container. +- CycloneDX: A lightweight SBOM standard designed for use in application security contexts and supply chain component analysis. +- SPDX (Software Package Data Exchange): A file format used to document information on the software licenses under which a given piece of computer software is distributed. +- SWID: A formal industry standard used by various commercial software publishers designed with software inventory and entitlements management in mind. # Motivation [motivation]: #motivation @@ -117,4 +117,4 @@ The above RFC was inspired by [NTIA SBOM Formats and Standards Whitepaper - VERS [NTIA-WP]: https://docs.google.com/document/d/1KEMRrjbMd6FV7-ZFCk-AVVi-QY7qRiYiylxFFUc5Y_8/edit# [CDX]: https://cyclonedx.org/ [SPDX]: https://spdx.dev/ -[SWID]: https://nvd.nist.gov/products/swid \ No newline at end of file +[SWID]: https://nvd.nist.gov/products/swid From 2d94122e8024802021fd0a7e0f1a7dd2dfc916d8 Mon Sep 17 00:00:00 2001 From: Sambhav Kothari Date: Thu, 29 Jul 2021 12:17:07 +0100 Subject: [PATCH 07/11] Update RFC as per suggestions from the WG Signed-off-by: Sambhav Kothari --- text/0000-sbom.md | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/text/0000-sbom.md b/text/0000-sbom.md index 0784f1e9f..2b5f1c033 100644 --- a/text/0000-sbom.md +++ b/text/0000-sbom.md @@ -58,13 +58,17 @@ Having a structured and consistent SBOM that can be consumed by downstream syste [what-it-is]: #what-it-is Currently the SBOM is defined in the `.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 `.bom.`, `launch.bom.` and `build.bom.` instead where `` will be `cdx.json` for CycloneDX documents and `spdx.json` for SPDX documents. +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 `.bom.`, `launch.bom.` and `build.bom.` instead where `` will be `cdx.json` for CycloneDX documents and `spdx.json` for SPDX documents. A buildpack can also output the `bom` in multiple formats i.e. both CycloneDX and SPDX. 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, 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 a stack author may choose to provide a `/cnb/image/merge-bom` binary in the base-image that takes in the above `/layers/config/sbom` folder as its input alongside the location of the final merged `build.bom.` and `launch.bom.`. The `merge-bom` binary can read as input the `/layers/config/sbom` to merge the build and launch `bom` as it sees fit and output them to a combined `build.bom.` and `launch.bom.`. The lifecycle will be responsible for invoking the `merge-bom` binary if it finds one, otherwise it will skip generating the merged bom. +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. + +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. + +Since we will be preserving the original output files and if a buildpack chooses to output in both SPDX and CycloneDX, the lifecycle may eventually add support for SPDX merging in a future version if merging SPDX documents becomes better defined/efficient. # How it Works [how-it-works]: #how-it-works @@ -77,9 +81,11 @@ which looks like - ![](https://user-images.githubusercontent.com/1714486/125960784-2795510d-511f-40fb-91f2-f9f97eeb573b.png) +This will however be better defined in a subsequent RFC. + # Backwards compatibility -TODO +Since we will not be merging the new formats with the legacy CNB format, we can just output the merged CNB formatted SBOM as a separate file. # Drawbacks [drawbacks]: #drawbacks @@ -102,7 +108,7 @@ 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. -- If the project will be responsible for providing some reference implementation of `merge-bom`. If yes, should it support `CycloneDX` as its first format? +- Restore/export logic for SBOM files. This will be covered in a subsequent RFC. # Spec. Changes (OPTIONAL) [spec-changes]: #spec-changes From 1fe273b71f52736c52824df1744933315791d8d9 Mon Sep 17 00:00:00 2001 From: Sambhav Kothari Date: Thu, 12 Aug 2021 20:22:10 +0530 Subject: [PATCH 08/11] Add motivation for multiple SBOM formats Signed-off-by: Sambhav Kothari --- text/0000-sbom.md | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/text/0000-sbom.md b/text/0000-sbom.md index 2b5f1c033..cff4d48ba 100644 --- a/text/0000-sbom.md +++ b/text/0000-sbom.md @@ -54,6 +54,10 @@ Having a structured and consistent SBOM that can be consumed by downstream syste - Use of CycloneDX and SPDX 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 separate files. +## Why support multiple SBOM formats? + +The motivation for supporting multiple SBOM formats is because there is currently no clear leader in the SBOM space. SPDX and CycloneDX both specialize in different use cases - compliance and supply chain security respectively, and although both do have a lot of overlap, there is still loss of information when converting between the two. The other motivation is that the SBOM story doesn't end with their generation. Different users could have different SBOM consumers who support one format or the other. Leaving individual SBOM files intact allows users to post-process it later if needed without any loss in information. This allows users to flexibly use the Buildpacks API to generate a SBOM in the format that is most useful to them. + # What it is [what-it-is]: #what-it-is @@ -73,7 +77,14 @@ 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 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 will simply call out the `merge-bom` binary with the appropriate inputs if one is provided, otherwise it will skip generating them. +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. + +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 - + +- `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 From a6a0561e67e03aa7b625b974ab1f27fed8068df3 Mon Sep 17 00:00:00 2001 From: Sambhav Kothari Date: Wed, 8 Sep 2021 19:30:02 +0100 Subject: [PATCH 09/11] Add sbom format to buildpacks toml Signed-off-by: Sambhav Kothari --- text/0000-sbom.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/text/0000-sbom.md b/text/0000-sbom.md index cff4d48ba..106a28d62 100644 --- a/text/0000-sbom.md +++ b/text/0000-sbom.md @@ -64,6 +64,23 @@ The motivation for supporting multiple SBOM formats is because there is currentl Currently the SBOM is defined in the `.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 `.bom.`, `launch.bom.` and `build.bom.` instead where `` will be `cdx.json` for CycloneDX documents and `spdx.json` for SPDX documents. A buildpack can also output the `bom` in multiple formats i.e. both CycloneDX and SPDX. +Additionally the buildpack must also indicate the SBOM format(s) it exports using the in its `buildapck.toml`'s `sbom` key in the `buildpacks` table. + +The format of this key should look like - + +```toml +api = "0.x" + +[buildpack] +id = "" +name = "" +# This can be an array of supported SBOM formats by the buildpack. +# Valid array values are "CycloneDX" and "SPDX" as of this RFC. +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 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. @@ -74,6 +91,7 @@ Merging different formats (CycloneDX/SPDX/Legacy CNB format) is a non-goal and w Since we will be preserving the original output files and if a buildpack chooses to output in both SPDX and CycloneDX, the lifecycle may eventually add support for SPDX merging in a future version if merging SPDX documents becomes better defined/efficient. + # How it Works [how-it-works]: #how-it-works From 53bd3790408f863e91fc96c9a127c4ee2caf5d62 Mon Sep 17 00:00:00 2001 From: Sambhav Kothari Date: Wed, 22 Sep 2021 13:47:57 +0100 Subject: [PATCH 10/11] Add sbom restoration description Signed-off-by: Sambhav Kothari --- text/0000-sbom.md | 28 +++++++++++++--------------- 1 file changed, 13 insertions(+), 15 deletions(-) diff --git a/text/0000-sbom.md b/text/0000-sbom.md index 106a28d62..313ac5623 100644 --- a/text/0000-sbom.md +++ b/text/0000-sbom.md @@ -75,17 +75,15 @@ api = "0.x" id = "" name = "" # This can be an array of supported SBOM formats by the buildpack. -# Valid array values are "CycloneDX" and "SPDX" as of this RFC. -sbom = ["CycloneDX"] +# Valid array values are sbom media types based on https://www.iana.org/assignments/media-types/media-types.xhtml +sbom = ["application/vnd.cyclonedx+json", "text/spdx+json"] ``` 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,26 +93,27 @@ 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 `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.`. + -The output `bom` files could be uploaded to the registry following a format as proposed in https://github.com/sigstore/cosign/pull/439 +Note - Addition of any new SBOM formats that do not require a merged SBOM need not require an RFC in the future as it would ideally just be a minor change in the lifecycle to update the media type mappings to the file extension. If the SBOM format does require a merged SBOM an RFC would be needed to describe any merging logic along with the justification for supporting it over existing supported SBOM formats. -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 -Since we will not be merging the new formats with the legacy CNB format, we can just output the merged CNB formatted SBOM as a separate file. +Since we will not be merging the new formats with the legacy CNB format, we can just output the merged CNB formatted SBOM as a separate file as it currently exists (/layers/config/metadata.toml). We can continue added the legacy buildpack bom in the label for now if any buildpack generates it and remove it once we discontinue BP API versions <=0.6. # Drawbacks [drawbacks]: #drawbacks @@ -137,7 +136,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 From f1ca47144a7546a58aa375174388a3fd5372727f Mon Sep 17 00:00:00 2001 From: Sambhav Kothari Date: Thu, 30 Sep 2021 16:40:51 +0100 Subject: [PATCH 11/11] Add spec to the list of changes Signed-off-by: Sambhav Kothari --- text/0000-sbom.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-sbom.md b/text/0000-sbom.md index 313ac5623..cb0e8e158 100644 --- a/text/0000-sbom.md +++ b/text/0000-sbom.md @@ -103,7 +103,7 @@ For merging the CycloneDX `bom` files, the `lifecycle` binaries could replicate 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.`. -Note - Addition of any new SBOM formats that do not require a merged SBOM need not require an RFC in the future as it would ideally just be a minor change in the lifecycle to update the media type mappings to the file extension. If the SBOM format does require a merged SBOM an RFC would be needed to describe any merging logic along with the justification for supporting it over existing supported SBOM formats. +Note - Addition of any new SBOM formats that do not require a merged SBOM need not require an RFC in the future as it would ideally just be a minor change in the lifecycle and spec to update the media type mappings to the file extension. If the SBOM format does require a merged SBOM an RFC would be needed to describe any merging logic along with the justification for supporting it over existing supported SBOM formats. ## BOM Restoration