The Software Bill of Materials (SBOM) moved from optional artifact to contractual obligation faster than most defense contractors expected. In 2021 it was a recommendation buried inside Executive Order 14028. By 2026 it is a gate condition — every binary shipped to a U.S. or NATO customer must have a current, signed, machine-readable SBOM attached, and the pipeline that produced the binary must be able to prove, at audit time, that the SBOM was generated from the same sources, in the same build, that produced the artifact. This article walks the engineering decisions that determine whether your CI/CD pipeline survives that audit.
1. Why SBOM Became Defense-Mandatory
Four regulatory threads converged. Executive Order 14028 (May 2021) required federal software suppliers to provide SBOMs and laid the foundation for the NTIA "minimum elements." NDAA Section 1655 (FY2023, refined through FY2026 amendments) extended SBOM requirements to defense acquisitions, mandating that DoD prime contractors and subs provide SBOMs for any software delivered to the Department, with specific provisions on Chinese-origin components and adversary-nation suppliers. NIS2 applied parallel pressure across the EU defense base, requiring documented supply-chain risk management for essential and important entities. NIST SP 800-218 — the Secure Software Development Framework (SSDF) — codified SBOM generation as an expected practice for any vendor self-attesting under OMB M-22-18 and M-23-16.
The practical effect is that a defense software vendor without SBOM tooling in 2026 is not a competitive vendor. RFPs include SBOM clauses. Audits include SBOM checks. And a missing SBOM is treated the same way a missing test report is treated — as evidence that the supplier's engineering process is incomplete. The good news for engineering teams is that SBOM generation, once instrumented correctly, is cheap to maintain. The bad news is that "instrumented correctly" hides a long list of architectural decisions, most of which are made wrong the first time.
2. CycloneDX vs SPDX
Two SBOM formats matter: CycloneDX (originated at OWASP, now an Ecma standard) and SPDX (originated at the Linux Foundation, ISO/IEC 5962:2021). They cover the same conceptual ground — components, versions, licenses, hashes, relationships — but the dialects diverge in ways that matter for tooling.
CycloneDX is optimized for security use cases: native VEX support, first-class vulnerability fields, lightweight JSON, tight integration with the OWASP ecosystem (Dependency-Track, dependency-check). It is the format most security teams produce by default. SPDX is optimized for license and provenance use cases: richer license expression language, longer pedigree in open-source compliance audits, the ISO stamp that legal and procurement teams ask for in regulated industries.
Defense customers ask for both. NDAA-aligned contracts increasingly specify "SPDX 2.3 or later, or CycloneDX 1.5 or later," leaving the format choice to the supplier — until the customer's downstream tooling forces one or the other. The pragmatic pattern is dual-emit: generate a CycloneDX SBOM in the build for internal vulnerability tooling, then transform to SPDX at delivery time using a converter (the open-source cyclonedx-py, cdx2spdx, or the SPDX tools chain). Treat one as the source of truth and the other as a derived artifact; keep both versioned alongside the binary.
3. Build-Time vs Post-Build SBOM Generation
The single largest determinant of SBOM credibility is when in the pipeline the SBOM is produced. There are two camps. Post-build scanners (Trivy, Snyk, GitHub native dependency graph in scan mode) ingest a finished container image or binary and reverse-engineer its components. Build-time generators (Syft when wired into the build, cdxgen, language-specific tooling like cargo cyclonedx, mvn cyclonedx, npm sbom) observe the actual build process and emit the SBOM from the resolved dependency graph the build used.
Only build-time generation is credible at audit. The reason is simple: a post-build scanner identifies what it can see — it cannot distinguish between a library that is statically linked into the binary and a library that was pulled in for a build-time tool but never shipped. It cannot see private registries the scanner does not have credentials to. It cannot see compile-time code generation. A reviewer asking "how do you know this SBOM is complete?" gets an actionable answer only when the SBOM was produced by the build itself, with provenance back to the lockfiles. Post-build scanning is a useful second opinion. It is not the primary artifact.
In practice teams converge on a stack of Syft for OS and container layers, language-native generators (cargo, npm, pip, mvn, go-licenses with CycloneDX output) for source components, cdxgen when polyglot repos need a single pass, and Trivy or GitHub's native SBOM export as the post-build cross-check. The build pipeline merges the language-native outputs into a single CycloneDX document, signs it, and attaches it to the released artifact.
4. SBOM Signing and Attestation
An unsigned SBOM is not evidence. A reviewer cannot verify it was produced by the build that produced the binary; they cannot verify it has not been edited; they cannot prove the build environment was trusted. The fix is attestation — a signed statement, produced by the build system, binding the SBOM to a specific artifact hash.
The dominant primitives are sigstore/cosign for keyless signing (OIDC-bound certificates, transparency log in Rekor) and in-toto attestations for the statement format. An in-toto attestation has three parts: the subject (the artifact hash being attested), the predicate type (e.g. https://cyclonedx.org/bom, or the SLSA provenance type), and the predicate body (the SBOM itself, or the build provenance). Cosign signs the attestation, attaches it as an OCI artifact alongside the container image, and pushes the signature to the Rekor transparency log.
The SLSA framework (Supply-chain Levels for Software Artifacts) is the maturity model defense customers reference when they want a single number to anchor their requirements. SLSA 1 means provenance exists. SLSA 2 means it is signed and the build service is hosted. SLSA 3 means the build is isolated and the provenance is non-forgeable by the project itself. SLSA 4 means two-party review and hermetic, reproducible builds. Most defense contracts in 2026 ask for SLSA 3 as the floor for software delivered to operational environments; SLSA 2 is acceptable for non-deployed tooling. SLSA 4 remains rare outside of the highest-classification workloads.
5. Vulnerability Correlation Layer
An SBOM is a list of components; it is not, by itself, a vulnerability report. The correlation layer joins the SBOM against vulnerability databases (NVD, OSV, GitHub Advisory Database) to produce a per-artifact vulnerability list. This is where most teams discover that 80% of reported vulnerabilities in their SBOM are not exploitable in their context — the vulnerable function is never called, the affected configuration is never enabled, or the path is unreachable from any external surface.
The standardized way to communicate this is VEX (Vulnerability Exploitability eXchange). A VEX statement declares, for a specific CVE against a specific product version, one of four status values: not_affected, affected, fixed, or under_investigation, with a justification (e.g. vulnerable_code_not_in_execute_path). CycloneDX supports VEX natively; SPDX supports it via the CSAF (Common Security Advisory Framework) companion format. A defense customer reviewing your SBOM expects to see VEX statements explaining the open CVEs — not silence.
The operational workflow looks like: SBOM generated in build → vulnerability scan against OSV/NVD → triage in a tool like Dependency-Track → engineer files VEX statement with justification → VEX attached as a signed in-toto attestation alongside the SBOM. The customer's auditor sees a coherent story for every CVE.
Key insight: A defense pipeline that ships SBOMs without VEX statements drowns the customer in noise. Within six months the customer stops reading SBOMs because they cannot tell signal from background. The supplier who ships SBOM + VEX gets accreditation; the supplier who ships SBOM alone gets a remediation request for every "high" CVE in a transitive Go module. Triage your own vulnerabilities — your DevSecOps and zero-trust posture is judged by how well you correlate, not how many CVEs you raise.
6. CI Gate Logic
SBOMs and VEX statements only enforce supply-chain hygiene when the pipeline blocks on them. The gate sits between "build succeeded" and "release artifact promoted." Modern teams write the gate as a policy in Rego (Open Policy Agent) or Kyverno, evaluated against the SBOM and VEX inputs.
A workable policy enforces four rules. One: no critical CVEs without a VEX justification. Two: no components from a denylist of license families (AGPL in proprietary deliverables, anything with a U.S. export-controlled origin clause). Three: no components from sanctioned-nation registries (this is where NDAA 1655 lives — Chinese-origin packages flagged automatically). Four: the SBOM must be signed, the build provenance must claim SLSA 3 or higher, and the Rekor transparency log entry must exist.
Waivers are the place where most policies fail in practice. A blanket "ignore this CVE forever" override is the audit failure pattern. The pattern that survives audit is waiver with justification and expiry: the waiver file lives in the repo, is reviewed in a pull request, names the CVE and the artifact, contains a written justification (the same VEX justification fields), and has an expiry date. The pipeline accepts the waiver only while it is unexpired. Auditors love this pattern because it produces a written trail of risk decisions; engineers tolerate it because it is finite work.
7. Customer Delivery
The SBOM is not just a build artifact — it is a contract deliverable. Defense contracts in 2026 routinely include clauses on SBOM format, signing, delivery mechanism, and update cadence. Format negotiation typically happens at contract drafting: the supplier proposes CycloneDX 1.5 JSON, the customer counters with SPDX 2.3 because their downstream tool requires it, and the supplier commits to dual-emit. Delivery is usually via a customer-controlled registry or portal — never email attachments, which the customer's information security policy forbids.
The recurring-update obligation is the clause most suppliers underestimate. NDAA-aligned contracts typically require an updated SBOM with every patch release, every quarterly maintenance drop, and within 72 hours of any in-scope CVE disclosure. If your release process takes a week, you cannot meet a 72-hour clock. The fix is making SBOM emission automatic on every release, including patch releases, so that the SBOM is always current with the binary the customer is running. Suppliers who try to regenerate SBOMs manually after release end up explaining gaps to accreditation reviewers — see also how clearance and personnel constraints affect what your team can ship.
8. Audit Survival
The accreditation reviewer arrives. They ask three questions. Show me the SBOM for version 2.4.1, which we are running in production. Your registry returns the signed CycloneDX document with an in-toto attestation pointing to the binary hash the customer has installed. Show me the VEX statements for every "high" CVE in that SBOM. Your registry returns the VEX bundle, with justifications and dates. Show me how you would know, today, if a new CVE was disclosed against any component in this SBOM. You show them the continuous scan that runs against the SBOM corpus and the SLA on customer notification.
The pipeline that answers those three questions cleanly is the pipeline that survives. The pipeline that cannot — because the SBOM was generated post-hoc, or the VEX statements live in a spreadsheet, or no one tracks CVE disclosures against released SBOMs — is the pipeline that loses the contract on renewal. The investment is finite; the consequence of not making it is not. For the broader supply-chain framing, see our SBOM in defense software overview, the complete guide to defense cybersecurity, and the DevSecOps + zero trust deep-dive that sits one layer up from this pipeline work.