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