Standardizing the BOM format

[sambhav]

Currently since container images built by CNB don't follow a generic file system layout, they are not 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.

There are various standards for specifying a SBOM (Software bill of materials). The primary ones include

• SPDX
• SWID
• cyclonedx

It might be worth investigating all these formats as a standard recommendation for BOM. This may not be a part of the spec and instead can be a part of a set of guidelines and best practices (See buildpacks/rfcs#150)

This thread is meant to start a discussion on the pros and cons of each of these formats and how we can adopt this to provide better support for CVE detection and supply chain analysis.

[sambhav]

From what I could find https://github.com/DependencyTrack https://dependencytrack.org/ seems to be one of the most popular tools that use the above formats. It currently accepts cyclonedx and spdx with cyclonedx being the recommended format.

[sclevine]

Strongly agree that we should standardize on the BOM format. I'd actually support making the format we choose mandatory in the spec, so that we can build CVE-related tooling directly into pack.

Do you have any opinions about which format we select? I'd suggest that the format we choose should be the one most likely to be adopted by CVE scanning tools. It seems like SPDX and CycloneDX are the leading contenders (interesting issue: aquasecurity/trivy#140).

[nishakm]

Was there any discussion about what type of metadata needs to be collected in order to represent them in any of these SBoM formats?

[sclevine]

Questions from WG meeting on 4/18:

• Should we standardize on a single format? (trend towards yes, otherwise we fragment ecosystem, decrease buildpack compatibility)
• Is it possible to convert between formats?
• Should we pick the most popular format? What other criteria would we use to evaluate?

[sambhav]

Looking at https://cyclonedx.org/tool-center/ specifically tools like https://github.com/CycloneDX/cyclonedx-python and https://github.com/CycloneDX/cyclonedx-maven-plugin

These are killer features if I don't have to manually generate sboms in the relevant format and it can automatically figure it out from files that buildpacks themselves. (package.json, pom.xml, requirements.txt etc.)

It seems to support node, python, go, rust, php, maven, gradle, bundler,.Net out of the box and all these tools are part of the project that maintains the spec. I think this roughly covers the primary heroku and paketo buildpacks that are supported.

[sambhav]

It also looks like the cyclonedx CLI tools offers the ability to transform between different sbom formats, swid and spdx included. https://github.com/CycloneDX/cyclonedx-cli#convert-command

along with other useful features like validating the sbom and diffing sboms.

[nishakm]

The reason I recommend SPDX is because they have a more comprehensive set of metadata and CycloneDX's metadata is a subset of those. If you can codify the metadata superset, you can transcribe it to either one of these formats.

[sambhav]

From my investigation it seems to be the other way around. CycloneDX's metadata seems to be a superset of SPDX v2.1/2.2 and you can convert cyclonedx boms to SPDX (cyclonedx also comes with a CLI that supports this). https://github.com/CycloneDX/cyclonedx-cli#convert-command

[abitrolly]

I also would not recommend SPDX, because it forces people to convert public domain dedication into several licenses, which leads to the dilution of metadata, and makes impossible to see how many authors preferred to opt out from copyright (e.g. SQLite),

[natalieparellano]

For others who may encounter this issue, this was implemented in https://github.com/buildpacks/rfcs/blob/main/text/0095-sbom.md