Software Bill of Materials (SBOM) for Defense: What Procurement Now Requires

A Software Bill of Materials (SBOM) is a machine-readable inventory of all software components, libraries, and dependencies that make up a software product. It is, in essence, the software equivalent of a physical manufacturing bill of materials: a structured list of every ingredient that went into the final product, including the version of each component and the known vulnerabilities associated with each version at the time of delivery.

SBOM requirements in defense procurement are no longer emerging — they are present. US Executive Order 14028 (May 2021) required SBOM delivery for software sold to the federal government. The DoD Software Modernization Strategy references SBOM as a supply chain security requirement. The EU Cyber Resilience Act (CRA), which entered into force in 2024, will require SBOMs for products with digital elements sold in the EU market — covering a wide range of defense-adjacent products. Defense software vendors who cannot produce compliant SBOMs will be disqualified from procurement opportunities.

What an SBOM Is: Machine-Readable Component Inventory

An SBOM lists every software component that is included in a software product, either directly (a library the development team explicitly added as a dependency) or transitively (a library that one of those direct dependencies itself depends on). For a modern software application built with standard open-source components, the transitive dependency tree typically contains hundreds to thousands of components — far too many to track manually.

The NTIA (National Telecommunications and Information Administration) minimum elements for an SBOM define what each component entry must contain: the component supplier name, the component name, the component version, other unique identifiers (package URL or hash), the dependency relationship (how the component fits into the broader component tree), the author of the SBOM data, and a timestamp.

The operational value of an SBOM is its use for vulnerability management. When a new critical vulnerability is disclosed — Log4Shell (CVE-2021-44228) is the canonical example — an organization with SBOMs for all its deployed software can immediately query those SBOMs to identify which systems include Log4j and at what version, prioritizing remediation. An organization without SBOMs must manually investigate each system, which in a large defense environment can take weeks and leaves critical systems unpatched in the interim.

Regulatory Drivers: EO 14028, NTIA, and EU Cyber Resilience Act

US Executive Order 14028 (Improving the Nation's Cybersecurity) was signed in May 2021 following the SolarWinds supply chain attack, which demonstrated how a single compromised software update pipeline could compromise thousands of downstream organizations, including multiple federal agencies. Section 4 of the order specifically requires that software providers selling to the federal government provide SBOMs. OMB guidance implementing EO 14028 has progressively tightened SBOM requirements for federal contractors.

NTIA minimum elements (published June 2021) provide the baseline standard for what constitutes a compliant SBOM. These elements are the minimum — contracts may specify additional requirements such as specific SBOM formats, inclusion of transitive dependencies to a specified depth, or integration with vulnerability advisory systems.

The EU Cyber Resilience Act applies to products with digital elements placed on the EU market. Products in the "important" and "critical" categories (including many defense-adjacent hardware and software products) face mandatory third-party conformity assessments. While the CRA does not mandate SBOMs explicitly in all cases, the essential cybersecurity requirements it defines — vulnerability handling, security updates, disclosure of security-relevant component information — are most practically fulfilled through SBOM generation and maintenance. EU defense programs and products sold in EU markets should plan for SBOM requirements as part of CRA compliance.

SBOM Formats: SPDX vs CycloneDX

Two formats dominate the SBOM ecosystem: SPDX and CycloneDX. Both are open standards, both are machine-readable, and both can represent the same underlying component data. The choice between them is primarily a function of tool support and use case emphasis.

SPDX (Software Package Data Exchange) is an ISO standard (ISO/IEC 5962:2021). It was originally developed by the Linux Foundation and has the deepest roots in the open-source license compliance community — SPDX began as a license tracking format and was extended to cover security use cases. SPDX is supported by a wide range of tools and has strong integration with the NTIA minimum elements specification. SPDX documents can be serialized as tag-value, JSON, YAML, or RDF-XML.

CycloneDX is an OWASP standard designed specifically for security use cases from inception. CycloneDX has stronger support for vulnerability data integration (VEX documents, described below), supports additional artifact types (services, hardware, machine learning models), and has a more active tool ecosystem specifically oriented toward DevSecOps workflows. CycloneDX is serialized as JSON or XML.

For defense programs, the practical guidance is: both formats are acceptable under current US SBOM guidance; verify the specific format requirements in your contract and program documentation; generate both if tool support allows (Syft, described below, generates both); and ensure your SBOM management platform can consume the format you produce.

SBOM Generation in CI/CD: Syft and cdxgen

Syft (from Anchore) is the leading open-source SBOM generation tool for container images and filesystems. It supports both SPDX and CycloneDX output formats and handles a wide range of package ecosystems: npm, PyPI, Maven/Gradle, NuGet, Go modules, RubyGems, Cargo, Alpine APK, Debian/Ubuntu DPKG, and RPM. In a CI/CD pipeline, Syft runs as a build stage step after the container image is built but before it is pushed to the registry, generating an SBOM that is published as a build artifact alongside the image.

cdxgen is the OWASP-maintained CycloneDX generation tool, with particularly strong support for polyglot repositories (repositories containing code in multiple languages). cdxgen traverses the dependency manifests of multiple package managers simultaneously and produces a unified CycloneDX SBOM covering all components across all language ecosystems in the repository. This is especially relevant for defense software projects that combine, for example, a Python backend with a TypeScript frontend and Java middleware.

VEX: Vulnerability Exploitability eXchange

An SBOM tells you which components are present. A VEX (Vulnerability Exploitability eXchange) document tells you whether the vulnerabilities in those components are actually exploitable in the specific product context. The distinction matters because software composition analysis typically produces long lists of CVEs in transitive dependencies that are not actually exploitable: the vulnerable code path is not reachable in the application, the vulnerable component is used in a test-only context, or the configuration that enables the vulnerability is not present in the deployed product.

VEX statuses for each CVE-component pair are: "affected" (the vulnerability is present and exploitable), "not affected" (the vulnerability exists in the component but is not exploitable in this product), "fixed" (a remediated version is available and deployed), or "under investigation" (exploitability has not yet been determined). Defense procurement contracts increasingly require both an SBOM and a VEX document as a complete supply chain security deliverable. CISA has published guidance on VEX formats and minimum required content.