Software Bill of Materials (SBOM) in AppSec

A Software Bill of Materials (SBOM) is a structured, machine-readable inventory of every component — libraries, packages, modules, and their dependencies — that makes up a software product. Within application security, SBOMs serve as the foundational artifact for identifying vulnerable components, satisfying regulatory mandates, and managing third-party and open-source risk at scale. Federal policy, led by the May 2021 Executive Order 14028, has elevated SBOM from an optional practice to a compliance requirement for software sold to U.S. government agencies.

Definition and scope

An SBOM is a formal record containing the details and supply chain relationships of components included in a software product. The National Telecommunications and Information Administration (NTIA), which coordinated early U.S. SBOM standardization work, defines the minimum elements of an SBOM to include: supplier name, component name, version, unique identifier, dependency relationships, author of the SBOM data, and timestamp (NTIA Minimum Elements for an SBOM, 2021).

Three primary SBOM formats have achieved broad adoption across the industry:

  1. CycloneDX — Maintained by OWASP, optimized for security use cases including vulnerability disclosure and license compliance. Supports JSON and XML serialization.
  2. SPDX (Software Package Data Exchange) — An ISO/IEC standard (ISO 5962:2021) originally developed by the Linux Foundation, designed for license compliance and provenance tracking.
  3. SWID Tags (Software Identification Tags) — An ISO/IEC 19770-2 standard used primarily by enterprise asset management and endpoint security tooling.

CycloneDX and SPDX represent the dominant formats in application security workflows. CycloneDX is more tightly integrated with vulnerability databases and security tooling; SPDX carries broader adoption in open-source governance and legal compliance contexts. Practitioners selecting a format must evaluate toolchain compatibility, downstream consumer requirements, and whether the primary driver is security response or license auditing.

The scope of an SBOM extends across all layers of a software artifact: first-party code, direct open-source dependencies, transitive dependencies (dependencies of dependencies), commercial off-the-shelf components, and containerized base images. In containerized environments, SBOM scope must account for the operating system packages within the base layer — a dimension addressed specifically in container and Kubernetes application security practices.

How it works

SBOM generation integrates into the secure software development lifecycle at the build stage, though SBOMs can also be generated post-build through binary analysis. The operational workflow follows a discrete sequence:

  1. Discovery — Static analysis or package manager interrogation identifies all components present in source code or build artifacts.
  2. Enumeration — Each component is assigned identifiers such as CPE (Common Platform Enumeration) or PURL (Package URL) to enable unambiguous cross-referencing with vulnerability databases.
  3. Relationship mapping — Dependency graphs are constructed to distinguish direct from transitive dependencies, preserving chain-of-custody information.
  4. Vulnerability correlation — The component inventory is matched against the NIST National Vulnerability Database (NVD) and OSV (Open Source Vulnerabilities) database to surface CVEs affecting identified versions.
  5. SBOM signing and attestation — Cryptographic signatures are applied to the SBOM document using tooling compatible with the SLSA (Supply-chain Levels for Software Artifacts) framework, establishing integrity guarantees.
  6. Distribution and ingestion — SBOMs are delivered to software consumers (procurement teams, security operations centers, government agencies) in a machine-readable format for continuous monitoring.

Software composition analysis tools — including open-source projects like Syft (Anchore) and commercial platforms — automate steps 1 through 4. Integration with application security in CI/CD pipelines enables SBOM generation on every build, ensuring the artifact reflects the current dependency state rather than a point-in-time snapshot.

Common scenarios

Federal software procurement — Executive Order 14028 directed NIST to publish guidance on SBOM practices for federal procurement. NIST's subsequent publication, SP 800-204D (Draft), outlines SBOM integration strategies for agencies acquiring software. Vendors supplying software to federal agencies must produce SBOMs meeting NTIA minimum element standards.

Open-source vulnerability response — When a critical vulnerability such as CVE-2021-44228 (Log4Shell) affects a widely used library, organizations with current SBOMs can identify affected products within hours. Organizations without SBOMs require manual audits that, in documented response efforts, extended remediation timelines by days to weeks.

Mergers and acquisitions due diligence — Acquirers assess inherited software risk by requesting SBOMs from target companies. License obligations embedded in open-source components — GPL, AGPL, LGPL, Apache 2.0 — carry material legal implications that SPDX-formatted SBOMs surface explicitly.

Healthcare and medical device compliance — The FDA's 2023 guidance on cybersecurity in medical devices requires manufacturers to submit an SBOM as part of premarket submissions under Section 524B of the Federal Food, Drug, and Cosmetic Act, as amended by the Consolidated Appropriations Act, 2023.

Supply chain security for software — SBOMs underpin software supply chain integrity programs, providing the artifact necessary to verify that build outputs match declared inputs and to detect unauthorized component injection.

Decision boundaries

Not every organization faces the same SBOM obligations or operational readiness. Key decision boundaries include:

Regulated vs. unregulated sectors — Medical device manufacturers, federal contractors, and critical infrastructure operators face statutory or contractual SBOM mandates. Enterprises in unregulated sectors may adopt SBOMs voluntarily as a risk management control without a compliance driver.

Generation vs. consumption — Software producers generate SBOMs; software purchasers and operators consume them. The tooling, staffing, and process requirements differ substantially. Producers require build-time integration; consumers require ingestion pipelines and correlation engines.

Binary vs. source-level analysis — Source-level SBOM generation (from package manifests and lockfiles) produces higher fidelity dependency data. Binary analysis tools can generate SBOMs from compiled artifacts when source access is unavailable — relevant in third-party component audits — but accuracy degrades for obfuscated or stripped binaries.

Automated vs. manual generation — Automated SBOM generation through devsecops practices is the operationally sustainable model for organizations with multiple active software products. Manual SBOM construction is viable only for small, infrequently updated codebases and does not scale to continuous delivery environments.

SBOM completeness is a persistent challenge. Transitive dependencies can number in the hundreds for a single application — the npm ecosystem routinely produces dependency graphs exceeding 500 nodes for moderately complex Node.js applications — and incomplete enumeration of transitive components creates blind spots in vulnerability correlation.

References

📜 3 regulatory citations referenced  ·  🔍 Monitored by ANA Regulatory Watch  ·  View update log

Explore This Site

Regulations & Safety Regulatory References Tools & Calculators Password Strength Calculator