History of Software Bill of Material (SBOM)

Many people talk about software bills of materials. Few know about SBOM origins. I find it essential to understand the genesis of ideas. Let’s talk about the beginning of the SBOM.  

What is a Software Bill of Material?

First, we need to define the software bill of materials. What is an SBOM? Let’s read how others define 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.

SBOM, It’s More Than a List of Things

What other purposes does an SBOM provide besides being a list of things?  An SBOMs value is its nature 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 material allows computers to communicate with each other.  It allows computers to describe software components that make up a software system.

Albeit, 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?

Both, 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 foreshadow a future where SPDX subsumes the same context concerns as CycloneDX.

Regardless, why would you not use both right now?  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.

What Does This All Mean?

The key to using an SBOM successfully is not which format you choose.  It’s the context for the decision support capabilities you need for current license, vulnerability, and software component needs. Some folks will want you to choose one or the other.  Don’t let them.  Their impassioned claims of overlapping and cries of efficiencies are simply a distraction.  I think these folks get their kicks more from being software pundits than genuinely adding value to communities and organizations.

- About The Authors

Bill Bensing

Bill Bensing tranforms Shadow IT into legitimate software development organizations. Bill's recent thought-leadership is proving software devliery velocity and highly secure and compliant software are not mutally exclusive. He lives in Tampa Bay, FL, area.

Follow Bill on Social Media

• 
•