universal security Commons: 4/5

Software Bill of Materials (SBOM)

Also known as:

1. Overview

Software Bill of Materials (SBOM) is a pattern for building resilient value creation systems.

Problem: Modern software is not built, it is assembled. Applications are composed of hundreds of open-source and third-party components, which in turn have their own dependencies, creating a complex and often opaque software supply chain. When a new vulnerability is discovered in a common library (like Log4j), organizations struggle to answer a basic question: “Are we affected?” They have no easy way to know which of their applications use the vulnerable component.

Context: You are building or operating a software system and need to manage the risk inherent in your software supply chain. You need a formal, machine-readable inventory of all the components, libraries, and dependencies that make up your application.

2. Core Principles

Generate and maintain a Software Bill of Materials (SBOM) for your applications. An SBOM is a formal, machine-readable inventory of software components and their dependencies. It is analogous to a list of ingredients on a food package.

An SBOM should include, for each component:

  • Component Name
  • Component Version
  • Supplier Name
  • License Information
  • Unique Identifier (e.g., a PURL or CPE)

SBOMs can be generated by tools that scan source code, build artifacts, or container images. Once generated, they should be stored and used to:

  • Track Vulnerabilities: When a new vulnerability is announced, you can query your SBOMs to immediately identify all affected applications.
  • Manage Licenses: Ensure compliance with the licenses of all your dependencies.
  • Assess Supply Chain Risk: Understand your exposure to risks from specific suppliers or components.

3. Rationale

An SBOM provides the transparency needed to manage a modern software supply chain. It:

  • Enables Rapid Vulnerability Response: Turns a months-long manual investigation into a seconds-long database query.
  • Provides Foundational Transparency: You can’t secure what you don’t know you have.
  • Is Becoming a Standard Practice: Driven by government initiatives (like the U.S. Executive Order on Cybersecurity), SBOMs are becoming a standard requirement for software producers.

4. Consequences

  • Positive:
    • A dramatic improvement in the ability to respond to supply chain vulnerabilities.
    • Increased transparency and trust between software producers and consumers.
    • A foundational component for a mature software supply chain security program.
  • Negative:
    • Tooling is still maturing: The ecosystem of tools for generating, storing, and analyzing SBOMs is still evolving.
    • Can be complex to generate: Accurately generating a complete SBOM for a complex application can be challenging.
    • It’s not a silver bullet: An SBOM tells you what you have; you still need other tools and processes to act on that information (e.g., vulnerability scanning and patching).

5. Application Context

Best Used For:

  • Value creation systems requiring strong privacy and security foundations
  • Organizations operating in regulated environments
  • Systems handling sensitive data or requiring high trust

6. Known Uses

  • U.S. Federal Government: The 2021 Executive Order on Improving the Nation’s Cybersecurity mandates that vendors providing software to the federal government must provide an SBOM.
  • CycloneDX and SPDX: Two of the most common, open-source standards for the SBOM data format.
  • Software Composition Analysis (SCA) Tools: Many commercial and open-source SCA tools can generate SBOMs.