SBOM (Software Bill of Materials): Why It Matters
First developed as part of our LinkedIn content series, June 2026. Expanded and updated for this site.
SBOM (Software Bill of Materials): Why It Matters
On March 29, 2024, a Microsoft engineer noticed something odd in SSH connection latency benchmarks and traced it to a backdoor planted in the xz compression library (CVE-2024-3094) --- a supply chain compromise cultivated over two years of patient social engineering against a single open-source maintainer. The backdoor was days away from shipping in stable releases of every major Linux distribution. For most organizations, the immediate question was identical to the one Log4Shell (CVE-2021-44228) forced in December 2021: "Do we use this component, and where?"
Organizations with SBOMs answered in minutes. Everyone else started sending emails.
Why This Matters Now
Three forces have converged to make SBOMs non-optional for any organization that sells to the federal government or operates in a regulated industry:
Executive Order 14028 (May 2021) made software supply chain transparency a federal procurement requirement -- agencies can require SBOM delivery for the software they buy, and the follow-on OMB attestation deadlines have passed. Vendors that cannot produce machine-readable SBOMs are losing contracts today.
The xz incident (CVE-2024-3094, March 2024) demonstrated that supply chain attacks target the weakest human link, not the weakest code. The only defense at speed is knowing exactly what you ship and run --- component by component, version by version.
CISA's software transparency push continues to expand. Federal contractors, FedRAMP-authorized vendors, and CMMC-assessed defense industrial base companies all face SBOM requirements that did not exist three years ago. Cyber insurance questionnaires now routinely ask about SBOM practices.
The question is no longer whether you need SBOMs. It is whether your SBOM program is mature enough to withstand the next xz-class event.
What an SBOM Is
An SBOM is a formally structured, machine-readable inventory of every component in a piece of software. Think of it as a nutritional label: just as a food label lists every ingredient so consumers can identify allergens, an SBOM lists every software component so organizations can identify vulnerabilities, licensing risks, and supply chain concerns.
An SBOM typically documents:
- Component name and version --- every library, module, framework, and package
- Supplier --- who authored or distributes the component
- Unique identifier --- a package URL (purl) or CPE that enables automated matching against vulnerability databases
- Dependency relationships --- direct, transitive, development-only
- Timestamp and author --- when the SBOM was generated and by what tool or organization
A modern application is not a monolith. A typical Node.js application pulls 300-1,500 transitive dependencies. A Java enterprise application routinely exceeds 2,000. A containerized deployment adds the OS package set on top. Without an SBOM, the only way to know what is inside is to look --- manually, every time, for every application. With an SBOM, the answer is documented and queryable in seconds.
The Two Standard Formats
Two standards dominate the SBOM landscape. Both are actively maintained, widely tooled, and accepted by federal agencies.
SPDX (Software Package Data Exchange)
Maintained by the Linux Foundation. ISO/IEC 5962:2021 standardized. Originally built for open-source license compliance, now expanded to cover security use cases with the SPDX 3.0 security profile.
Strengths: License compliance and legal analysis, granular file-level and snippet-level tracking. Supports JSON, YAML, XML, RDF, and tag-value formats.
Current version: SPDX 2.3 (stable), SPDX 3.0 (released 2024, adds security profile with VEX support).
CycloneDX
Maintained by OWASP. Ecma International standard (Ecma-424). Designed from the ground up for security workflows.
Strengths: Native vulnerability embedding, VEX support, extended BOM types including Hardware BOM (HBOM), Machine Learning BOM (ML-BOM), Cryptography BOM (CBOM), and SaaS BOM (SaaSBOM). Supports JSON, XML, and Protocol Buffers.
Current version: CycloneDX 1.6.
Choosing Between Them
| Use Case | Recommended Format |
|---|---|
| Open-source license compliance | SPDX |
| Vulnerability management primary | CycloneDX |
| Federal procurement compliance | Either (both accepted) |
| Maximum security tool compatibility | CycloneDX (slightly broader) |
| Both license and security | CycloneDX 1.6 or SPDX 3.0 |
In practice, the formats are converging. SPDX 3.0 added security profiles. CycloneDX has always supported license data. The choice between them matters less than the decision to produce SBOMs at all.
Executive Order 14028: The Federal Mandate
Section 4 of EO 14028 ("Improving the Nation's Cybersecurity," May 12, 2021) directed NIST to publish guidance on SBOMs for software sold to the federal government. The resulting requirements established that:
- Agencies may require software vendors to provide SBOMs conforming to NTIA minimum elements
- SBOMs must be machine-readable in SPDX or CycloneDX format
- Vendors must attest to secure development practices including supply chain transparency as part of their SDLC
- SBOM delivery can be made a procurement condition --- when the contract requires one: no SBOM, no contract
The ripple effects extend well beyond federal procurement: government contractors must provide SBOMs for software delivered under contract, commercial vendors with federal customers are adopting universally because maintaining separate build processes is more expensive than universal adoption, and frameworks like SOC 2, ISO 27001, and CMMC increasingly reference supply chain transparency.
NTIA Minimum Elements
The National Telecommunications and Information Administration published "The Minimum Elements for a Software Bill of Materials" in July 2021. These define the floor:
| Element | Description | Example |
|---|---|---|
| Supplier Name | Entity that creates/identifies components | "Apache Software Foundation" |
| Component Name | Designation assigned to the software unit | "log4j-core" |
| Version | Change identifier from previous version | "2.17.1" |
| Unique Identifier | Lookup key for the component | "pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1" |
| Dependency Relationship | Upstream component relationship | "log4j-core is a direct dependency of my-application" |
| Author of SBOM Data | Entity creating the SBOM | "Acme Corp Build System" |
| Timestamp | Date/time of SBOM assembly | "2025-03-15T14:30:00Z" |
Required practices include: automation (machine-generated, not hand-curated), frequency (every build, not every release), depth (all transitive dependencies), and distribution (delivered with the software or available via API).
The minimum elements are genuinely minimum. Mature programs add hash values for integrity verification, license data, build environment information, and vulnerability status via VEX.
How SBOMs Transform Vulnerability Management
The Pre-SBOM Response (Log4Shell, December 2021)
When CVE-2021-44228 dropped, organizations without SBOMs followed a painful workflow:
- Security team asks development: "Do we use Log4j?" --- hours to days for initial response
- Development checks build manifests --- misses transitive dependencies where Log4j was pulled in three layers deep
- Third-party software: contact vendors, wait for advisories --- days to weeks
- Infrastructure scanning: run tools, hope they detect the library in packaged applications --- coverage gaps everywhere
- Compile an incomplete affected-system list --- typically a week or more
- Begin remediation --- often 10+ days after disclosure, while exploitation was already widespread
The Post-SBOM Response
With SBOMs for all deployed software:
- CVE disclosed --- automated tools query all SBOMs for
log4j-coreversions < 2.17.0 --- seconds - Affected systems identified with version specificity and deployment context --- minutes
- Prioritized by internet exposure, asset criticality, exploit availability --- minutes to hours
- Patched versions validated against updated SBOMs --- automated
The difference between "we think we might use Log4j somewhere" and "here are 47 deployments running Log4j 2.14.1, prioritized by internet exposure" is the difference between a multi-week incident response and same-day remediation.
Continuous Monitoring Without Rescanning
SBOMs enable a model most organizations have not considered: when a new CVE is published, automatically match it against stored SBOMs without deploying a scanner or waiting for a scan window. No agents, no credentials, no coverage gaps for assets the scanner cannot reach. If the SBOM is accurate, the match is instantaneous and complete.
SBOM Generation: Where It Fits in the Pipeline
SBOM generation belongs in CI/CD, after the build and before deployment:
Build -> Test -> Generate SBOM -> Scan SBOM -> Store SBOM -> Deploy
Generating after the build ensures the SBOM reflects exactly what is deployed. Generating from source manifests alone (package.json, pom.xml) misses components added during the build process --- native binaries compiled in, OS packages in the container base image, build-time code generation.
Key tools: Syft (Anchore) for container images across 15+ ecosystems, cdxgen for complex build systems (Gradle multi-module, monorepos), Microsoft sbom-tool for Azure DevOps integration, GitHub Dependency Graph for automatic SPDX export via API.
VEX: The Missing Context Layer
An SBOM says your application includes Log4j 2.14.1. A vulnerability scan flags CVE-2021-44228. But what if your application uses Log4j only for local file logging and never processes untrusted JNDI lookup strings? The vulnerability exists in the component but is not exploitable in your context.
Vulnerability Exploitability eXchange (VEX) communicates this context:
| Status | Meaning |
|---|---|
| Not Affected | Vulnerable code path is not reachable in this product |
| Affected | Product is affected; remediation recommended |
| Fixed | Vulnerability existed but is fixed in this version |
| Under Investigation | Vendor is still analyzing exploitability |
VEX eliminates the noise that makes SBOM-based vulnerability matching overwhelming at scale. Without VEX, every component match is a finding. With VEX, only exploitable matches require action. The combination of SBOM + VEX represents the future of vulnerability communication: "here is what we include, and here is which vulnerabilities actually affect you."
VEX can be communicated through CycloneDX VEX (embedded or standalone), CSAF VEX (Common Security Advisory Framework profile), or OpenVEX (a dedicated open specification). Adoption is early but accelerating, particularly among vendors with federal customers.
Supply Chain Risk Beyond Vulnerabilities
SBOMs reveal dependency patterns that indicate supply chain risk independent of known CVEs:
- Single-maintainer dependencies --- critical components maintained by one person, as the xz incident demonstrated catastrophically
- Abandoned dependencies --- components with no updates in years, likely carrying unpatched vulnerabilities nobody has reported
- Deep transitive chains --- a dependency six levels deep is harder to update and easier to compromise without detection
- Namespace confusion --- similar package names across registries enabling typosquatting and dependency confusion attacks
When combined with build provenance attestations (SLSA --- Supply Chain Levels for Software Artifacts), SBOMs provide a verifiable chain of custody from source code to deployed artifact. This matters for procurement: can you prove that what you deployed is what you built from the source you reviewed?
The Contrarian Take: SBOM Quality Matters More Than SBOM Existence
Here is what nobody in the compliance community wants to hear: a bad SBOM is worse than no SBOM. An SBOM generated only from direct dependencies (missing transitives), generated from a stale lockfile (not the actual build), or generated without accurate version pinning creates false confidence. Teams believe they have answered the "do we use this?" question when they have actually answered it incorrectly.
The xz backdoor (CVE-2024-3094) lived in a compression library pulled transitively through systemd and OpenSSH. An SBOM that only captured direct dependencies would have missed it entirely --- and the team would have checked their SBOM, seen no match, and moved on while the backdoor sat in their infrastructure.
Depth matters. Accuracy matters. Frequency matters. Generating an SBOM once per release and calling it done is compliance theater that provides a false sense of security at exactly the moment you need real answers.
Building an SBOM Program
Step 1: Start with what you build. Integrate SBOM generation into CI/CD for internally developed software. This is the easiest starting point because you control the build process.
Step 2: Request SBOMs from vendors. Include SBOM requirements in procurement language. Many vendors already produce them for federal customers --- you may just need to ask.
Step 3: Centralize and analyze. Deploy SBOM management that can ingest from build systems and vendors, match components against vulnerability databases, and surface findings to your vulnerability management workflow.
Step 4: Operationalize. Use SBOMs as primary input: automated CVE-to-component matching on new disclosures, component age monitoring, license compliance automation, dependency risk scoring.
Step 5: Mature. Generate and consume VEX documents, implement SLSA build provenance alongside SBOMs, track across the full lifecycle (development through decommission), and use SBOM data for procurement decisions.
Key Takeaways
- SBOMs reduce "do we use this component?" from days/weeks to seconds/minutes.
- EO 14028 made SBOM delivery a federal procurement expectation that agencies can enforce contractually. Compliance dates have passed.
- CycloneDX for security-focused workflows, SPDX for license compliance, either for federal acceptance.
- Generate in CI/CD after every build (not every release). Include all transitives. Store centrally.
- VEX eliminates noise by communicating exploitability context alongside component inventory.
- A shallow or stale SBOM creates false confidence worse than no SBOM at all.
Frequently Asked Questions
Do SBOMs replace vulnerability scanners?
No. SBOMs and scanners are complementary. SBOMs answer "what components are present?" and enable instant matching against new CVEs without rescanning. Scanners detect misconfigurations, runtime issues, and vulnerabilities in components the SBOM might miss (dynamically loaded plugins, runtime-resolved dependencies). Mature programs use both.
How often should SBOMs be regenerated?
Every build that produces a deployable artifact should produce a corresponding SBOM. At minimum, every release. The SBOM must represent exactly what is deployed --- if a build changes a single transitive dependency version, the SBOM must reflect it. Stale SBOMs are unreliable SBOMs.
What about proprietary third-party software we purchase?
Request SBOMs from vendors and include the requirement in procurement language. Many vendors already produce them for federal customers. For vendors that refuse, treat the product as opaque from a supply chain risk perspective and weight that opacity in procurement and risk decisions.
How do SBOMs relate to the Cryptography BOM (CBOM) requirement?
CycloneDX 1.6 introduced the Cryptography BOM profile, which inventories cryptographic algorithms, key lengths, and certificate dependencies alongside software components. This is increasingly relevant for post-quantum cryptography migration planning --- knowing which components use which algorithms is the prerequisite to migrating them. See our coverage of post-quantum compliance requirements.
Are SBOMs required for FedRAMP authorization?
FedRAMP does not yet mandate SBOM delivery as a standalone control, but the underlying EO 14028 secure software development attestation applies to FedRAMP-authorized vendors. Producing and maintaining SBOMs is a practical necessity for meeting that attestation. Expect explicit SBOM requirements in future FedRAMP revision cycles.
How Advisedly Helps
Advisedly ingests SBOMs in both SPDX and CycloneDX formats, automatically matching every component against its live CVE feed with sub-3-hour enrichment. When a new CVE drops --- like the next Log4Shell --- the platform instantly identifies every affected deployment across your inventory, prioritized by TRACE Score and mapped against 500+ compliance frameworks. No waiting for scanner plugins. No emails to development teams. The answer exists before the question finishes forming. The platform consolidates 80+ enterprise tools into one pane --- including the SBOM lifecycle from ingestion through continuous vulnerability matching.
Ready to answer "do we use this?" in seconds? Contact us at begin@advisedly.ai to see SBOM-driven vulnerability management in action.
<!-- LI hook: Do you use Log4j? With an SBOM, that answer takes seconds. -->