4 min read
Many people are talking about the software bill of materials, but few know about SBOM origins. I find it essential to understand the genesis of ideas, so let’s talk about the beginning of the SBOM. First, we need to define the software bill of materials. What is an SBOM? Let’s read how others define an SBOM.
What is an SBOM?
- A “Software Bill of Materials” (SBOM) is a nested inventory for software, a list of ingredients that make up software components. (NTIA – National Telecommunications and Information Administration).
- An SBOM is a nested inventory, a list of ingredients that make up software components. (Cybersecurity and Infrastructure Security Agency – CISA).
- A software supply chain is composed of the components, libraries, tools, and processes used to develop, build, and publish a software artifact. (Wikipedia)
I found many references to the NTIA definition as I searched for ways people defined SBOM. An SBOM is simply a list of “ingredients” that make up software. The concept borrows from traditional supply chain management term bill of materials. A bill of materials documents the ingredients of a manufactured good.
An SBOM is more than just a list of things
What other purposes does an SBOM provide besides being a list of things? An SBOM’s value is in its function as a data exchange format. A data exchange format is a standard way of talking for computers. The benefits of a data exchange format are how they establish clear expectations for the semantic (what a term means) and the syntax (how something looks). Software bills of materials are not for human consumption. They are for computer consumption. A software bill of materials allows computers to communicate with each other. It allows computers to describe software components that make up a software system.
There is not a single trusted source on the history of the software bill of materials. Software bill of materials started as a way to aggregate data about open source licensing for individual software components of a system. The two most common SBOM formats are SPDX and CycloneDX. SPDX began in 2010. Then, in 2017, OWASP (Open Web Application Security Project) started another SBOM - CyclondeDX. Â
What are SPDX and CYCLONEDX?
SPDX stands for “Software Package Data Exchange.” Per the Linux Foundation, “SPDX was created to provide a common data exchange format so information about software packages and related content could be collected and shared.” SPDX started as a pillar of the Linux Foundation’s Open Compliance Program. The Open Compliance Program presents a wide-ranging array of tools, training, and informative guidance to help companies comply with open source license obligations. The program intends to increase the adoption of open source and decrease FUD present in the marketplace. The primary focus of SPDX is open source license compliance.
Significantly, SPDX became a public standard (ISO/IEC 5962:2021) at the International Organization for Standardization (ISO) on September 9, 2021.
CycloneDX tracks licenses but focuses on creating security context. The primary use cases are vulnerability identification, license compliance, and outdated component analysis. The OWASP Dependency-Track tooling relies upon a CycloneDX SBOM. Dependency-Trak is an open-source Component Analysis platform that identifies software supply chain risks.
Which SBOM - SPDX or CYCLONEDX?
Use both! Do not get embroiled in this argument. Each format is specific to a problem. The contexts each format establishes are necessary for modern day software decision support.
SPDX’s primary focus is licensing. Although, I don’t believe it will be like that forever. ISO/IEC 5962:2021 defines SPDX as a specification that represents “a standard data format for communicating the component and metadata information associated with software packages.” The definition is also a statement of intention. Even though SPDX started as a context for open source license compliance, there seems to be an intention to allow it to generate a context for concerns other than license compliance. I foresee a future where SPDX subsumes the same context concerns as CycloneDX.
Choosing the right SBOM format for your needs
For now at least why would you not want to use both? Undeniably, they each solve differing problems well.
SPDX is suboptimal for contexts concerning security and vulnerability. The SPDX tooling ecosystem provides decision support for license compliance. There is little ecosystem support for SPDX as decision support for security or vulnerability management.
CycloneDX is great for vulnerability identification, license compliance, and outdated component analysis contexts. The CycloneDX ecosystem is geared more toward decision support for vulnerability identification and outdated component analysis.
The key to using an SBOM successfully is not about which format you choose. Rather, it’s about the context for the decision support capabilities you require for current license, vulnerability, and software component needs.
