Software Bill of Materials (SBOM)

Software Bill of Materials (SBOM) | CDA.Wiki | CDA.Wiki

# Software Bill of Materials (SBOM)

Definition

A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of all components, libraries, and dependencies that make up a software application. Think of it as a nutritional label for software: it tells you exactly what ingredients are inside, where they came from, and what version is in use. SBOMs enable organizations to track vulnerabilities, license compliance, and supply chain risks across their entire software portfolio.

How It Works

SBOMs are generated through static analysis of source code, build systems, or binary artifacts. The two dominant standards are:

SPDX (Software Package Data Exchange): An ISO/IEC standard (ISO 5962) maintained by the Linux Foundation. Uses a tag-value or JSON format to describe packages, relationships, and license information.

CycloneDX: An OWASP standard designed specifically for security use cases. Uses XML or JSON format and includes fields for vulnerability tracking, service dependencies, and hardware components.

The SBOM lifecycle follows these stages:

Generation: Tools like Syft, Trivy, or language-specific package managers (npm, pip, Maven) produce SBOMs during build or CI/CD pipelines.
Storage: SBOMs are versioned and stored alongside release artifacts. Dependency-Track and similar platforms serve as SBOM repositories.
Analysis: SBOMs are continuously cross-referenced against vulnerability databases (NVD, OSV, GitHub Advisory Database) to identify affected components.
Sharing: SBOMs are shared with customers, partners, and regulators on request, often as part of procurement or compliance processes.
Response: When a new vulnerability is disclosed (like Log4Shell), SBOMs enable rapid identification of affected systems across the entire portfolio.

Why It Matters

The software supply chain is the most underestimated attack vector in modern cybersecurity. The average enterprise application contains over 80% open-source code. When a vulnerability like Log4Shell (CVE-2021-44228) drops, organizations without SBOMs spend days or weeks figuring out where the vulnerable component exists in their environment. Organizations with SBOMs answer that question in minutes.

Executive Order 14028 (May 2021) requires federal software suppliers to provide SBOMs. The EU Cyber Resilience Act extends similar requirements to products sold in European markets. FDA guidance requires SBOMs for medical devices. These are not suggestions; they are procurement requirements with real consequences.

Beyond compliance, SBOMs reduce mean time to remediation (MTTR) for supply chain vulnerabilities by orders of magnitude. They also expose shadow dependencies, components that nobody knew were present but that carry critical vulnerabilities.

Real-World Applications

Healthcare: Medical device manufacturers provide SBOMs to the FDA as part of premarket submissions, enabling post-market vulnerability monitoring.
Financial Services: Banks require SBOMs from third-party software vendors as part of vendor risk management programs.
Federal Government: GSA FedRAMP now includes SBOM requirements for cloud service providers seeking authorization.
Manufacturing: OT/ICS environments use SBOMs to track firmware components in industrial control systems.
Open Source Projects: Major projects like Kubernetes publish SBOMs with every release, enabling downstream consumers to track component risks.

CDA Perspective

CDA positions SBOMs within the Vulnerability & Surface Defense (VSD) domain under the Continuous Surface Reduction (CSR) methodology. You cannot reduce your attack surface if you do not know what that surface is made of. SBOMs are the foundation of surface awareness.

Our operational approach:

M-VSD-R02 conducts software composition analysis and generates baseline SBOMs during reconnaissance
M-VSD-B01 integrates SBOM generation into CI/CD pipelines so every build produces an updated inventory
M-VSD-H01 configures automated vulnerability correlation between SBOMs and threat feeds
CDA.Now ingests SBOM vulnerability data to surface real-time supply chain risk in the threat intelligence dashboard

Under Zero Possession Architecture, CDA helps clients generate and manage their own SBOMs without requiring access to source code. The tooling runs in the client's environment; CDA provides configuration, training, and validation.

Key Takeaways

SBOMs are machine-readable inventories of all software components and dependencies
Two dominant standards exist: SPDX (ISO standard) and CycloneDX (OWASP standard)
Federal, EU, and FDA regulations increasingly mandate SBOM production and sharing
SBOMs reduce vulnerability response time from days to minutes (as proven by Log4Shell)
SBOM generation should be automated in CI/CD pipelines, not treated as a one-time exercise
Organizations should require SBOMs from all software vendors as part of procurement

Table of Contents

Definition

How It Works

Why It Matters

Real-World Applications

CDA Perspective

Key Takeaways

Related CDA Missions

Discussion

The Academy

The Command Post

The Armory