“SBOM” should not exist! Long live the SBOM.

In 2008, my professional career led me to work on supply chain security for the pharmaceutical industry. I learned a lot from that experience. One of the most important lessons was the value of simplicity in standards development.

Fast forward four years to 2012, I started researching and working on supply chain security for build pipelines and the software and hardware devices my employer brought to market. My requirements have evolved over time; however, one thing remains the same; the need to inventory all software and hardware components, along with any services the software relied on is essential for transparency and traceability. These fundamental principles along with many of the lessons learned working on supply chain security in the pharmaceutical industry, formed the basis for the object model in OWASP Dependency-Track and what would later become the OWASP CycloneDX Bill of Materials (BOM) standard.

BOMs are not a new concept. Their use in manufacturing have been widespread since the 1970’s. In the manufacturing world, Product Lifecycle Management (PLM) is the set of practices that integrates data, processes, business systems, and people to help bring products to life, and to eventually retire them. The software industry has a similar approach called the Software Development Life Cycle (SDLC) which serves the same purpose. Within PLM, the BOM serves specific purposes based on the lifecycle of the product. For example, if the product is being planned, a Planning BOM may be used. If the product requires parts to be procured, a Procurement BOM is often used. When the product is being engineered, an Engineering BOM (eBOM) is used, and when the product goes through the manufacturing process, a Manufacturing BOM (mBOM) is used. In all cases, the complete inventory, regardless of what type of component it is, is documented in the BOM with information specific to the lifecycle and intended audience.

When I began working in software supply chain security in 2012, the terms “SBOM” and “Software Bill of Materials” were unknown to me. I had full stack requirements, like I do today, so confining a BOM to such a narrow set of things did not occur to me. It wasn’t until 2018 that I first heard the term when the National Telecommunications and Information Administration (NTIA) kicked off their SBOM initiatives.

What is perplexing is the question of why BOMs are being intentionally limited to only software components. Imagine a BOM for an automobile that was only capable of describing plastic parts, and other BOM types were necessary to describe the aluminum, steel, leather, and carbon fiber parts. Now imagine having a Plastic Parts BOM without any indication about what lifecycle the product is in. Should you order the plastic parts? Do they need to be engineered or manufactured? Perhaps they were delivered with the final goods. Who knows? Lifecycle is omitted from the conversation. Obviously, PLM does not operate this way, and for good reason. It’s unfortunate the software industry is subjected to an arcane approach that is both limited in scope and without lifecycle context.

A common myth is that SBOMs will be a roadmap to the attacker. This myth is addressed in SBOM Myths vs Facts. However, assumptions are made pertaining to lifecycle, specifically, that SBOMs are intended for software consumers. In my experience, the overwhelming majority of SBOMs created and consumed today are used for internal purposes, without the intent of ever being distributed. If an SBOM contained architecture design documents, threat models, or information about how the software was created (formulation), it would absolutely provide a roadmap to the attacker. This type of information is exceptionally useful during the design, implementation, and testing phases of the SDLC, and many organizations are producing such content for inclusion in internally accessible SBOMs. Lifecycle matters. Omitting it from the conversation is careless and introduces confusion to the market.

When the CycloneDX BOM standard was created, the term “BOM” was used throughout the specification because it can represent full-stack inventory including software, firmware, hardware, and services. As a security architect and leader, I care about the full stack, especially services since they can dramatically increase the attack surface. Software hasn’t lived in a vacuum for 20 years. Modern software regularly relies upon services to provide just-in-time information from the Internet or from the environment the software is operating in. It may also fetch updates from the manufacture’s website. In many cases, services make up a substantial part of an applications inventory. In the case of “serverless” applications, services may make up the entire inventory. At a minimum, the services an application relies on in its default configuration should be a requirement for any organization requesting BOMs from suppliers. Omitting services from a BOM provides purchasers insight about a supplier’s lack of maturity and subsequent risk.

The term “SBOM” intentionally omits services, hardware, and other traditional non-software inventory, nor does it communicate lifecycle to the target audience. Elementary definitions of SBOM describe it as a “simple list of ingredients”. However, in practice the term is confusing as it means different things to different people based on their role and data expectations. As a result, the term should not exist. So, what should we use instead? That’s a great question that I don’t really have an answer to. But here’s a few ideas.

• Cybersecurity Bill of Materials (CBOM) — Since security is the primary use case and main driver for SBOM adoption, “CBOM” may be useful since it doesn’t describe the “what”, it describes the purpose. If lifecycle was a requirement of CBOM, this would be an ideal term in my opinion.
• SDLC specific BOM terminology including Design BOM (DBOM), Implementation BOM (IBOM), Testing BOM (TBOM), Release BOM (RBOM), and Operational BOM (OBOM). By the way, OBOM is a common practice and is an observed behavior within BSIMM. OBOM is also supported by CycloneDX.
• Reuse PLM terminology including eBOM to describe design documents and threat models, mBOM to describe full stack inventory along with formulation, and simply BOM to describe the inventory itself.

With the popularity of the NTIA SBOM initiative and the subsequent Executive Order requiring SBOM for U.S. federal procurements, the term “SBOM” as been forever cemented in the lexicon of software terminology. I’m reminded of this daily from the frequent vendor pitches I get on LinkedIn or the SBOM startup of the week appearing in my Twitter feed. The CycloneDX team even had to update their website replacing BOM with SBOM for SEO purposes, thus feeding into this nonsensical mess.

Alas, long live the SBOM.