-
Notifications
You must be signed in to change notification settings - Fork 71
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
118 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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 `<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. | ||
|
|
||
| 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 <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. | ||
|
|
||
| # 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 |