What Is a Software Bill of Materials (SBOM)?

Most organizations deploying software in federal environments have a reasonable idea of what the software does. What they often can’t tell you—at least not quickly—is exactly what’s inside it. Which open-source libraries. Which third-party components. Which versions. Which of those components have known vulnerabilities sitting in production right now.

That’s the problem a Software Bill of Materials is designed to solve. Not theoretically. Practically—when an incident happens, when a zero-day drops, or when an auditor asks you to trace a vulnerability back to every affected system you operate.

The Log4Shell vulnerability in late 2021 made this problem viscerally real across the federal enterprise. Organizations scrambled to identify whether Log4j was present in their environments. Some took days. Some took weeks. A few still weren’t sure. The ones with mature software transparency practices had a material advantage. They knew what they had—and where it was.

An SBOM doesn’t prevent vulnerabilities. What it does is give you the inventory you need to respond intelligently when they surface. That’s a different kind of value—and it’s the kind that actually matters during an incident, an assessment, or a supply chain review.

This article covers what a Software Bill of Materials is, why it’s become a federal priority, how organizations use it operationally, and where implementation gets complicated in practice.

What Is a Software Bill of Materials?

The concept borrows directly from manufacturing. A physical bill of materials lists every part, component, and raw material in a product. If a supplier’s bolt fails, the manufacturer knows exactly which assemblies are affected. Software has always needed an equivalent—it just took a series of high-profile supply chain compromises to make the industry take it seriously.

A Software Bill of Materials is a structured, machine-readable inventory of every component that makes up a software artifact. That includes first-party code written by the developer, open-source libraries pulled in as dependencies, third-party commercial components, and nested dependencies—libraries that other libraries depend on. Modern software applications commonly contain hundreds of these components. Some enterprise platforms contain thousands.

Each entry in an SBOM typically captures: the component name, the supplier or maintainer, the version, a unique identifier (commonly a CPE or PURL), and the license under which it’s distributed. More mature SBOMs may also include cryptographic hashes for integrity verification, known vulnerability identifiers, and provenance metadata—information about where the component came from and how it was built.

The NTIA defines a minimum viable SBOM as containing: supplier name, component name, version, unique identifiers, dependency relationships, the author of the SBOM, and a timestamp. That’s the floor. Useful SBOMs in operational environments typically go further—but starting there establishes the baseline that federal policy now expects.

Why SBOMs Matter in Federal Environments

Federal organizations have always operated on the assumption that software acquired through proper procurement channels is reasonably trustworthy. The SolarWinds compromise changed that calculus in a significant way. Threat actors had embedded malicious code into a legitimate, digitally signed software update—meaning traditional trust signals provided no meaningful protection. The software looked right. It passed signature verification. It came through an established vendor relationship. And it was compromised.

Executive Order 14028, signed in May 2021, was partly a direct response to that event. Among its requirements: NIST was directed to publish guidance on software security practices, and federal agencies were directed to require SBOMs from software vendors as part of the procurement process. That wasn’t a soft recommendation. It was a mandate that cascaded into acquisition policy.

OMB guidance (M-22-18 and M-23-16) followed, establishing requirements for agencies to collect SBOMs from software producers and to integrate software security attestations into procurement. The Cybersecurity and Infrastructure Security Agency (CISA) has since published additional resources—reference documents, minimum element definitions, and sector-specific guidance—to help agencies build out operational SBOM programs.

The mission case is straightforward. Federal systems depend on software. That software depends on components. Some of those components have vulnerabilities. Without an SBOM, identifying where a specific vulnerable component lives across a system portfolio requires manual investigation—which takes time the mission often can’t afford. With an SBOM, the question becomes a query. That difference matters when a critical CVE drops on a Friday afternoon.

How Organizations Actually Use SBOMs

Collecting SBOMs is the easy part. The harder question is: what do you do with them? Organizations that treat SBOMs purely as procurement artifacts—something to collect and file—aren’t actually getting the operational value. The value comes from operationalizing the data.

Vulnerability Management

The most immediate use case is vulnerability correlation. When a new CVE is published, an organization with machine-readable SBOMs can query their inventory to identify which products contain the affected component and which version. That query replaces what would otherwise be a manual investigation across vendor documentation, patch bulletins, and internal application registries—all of which are often incomplete.

This works best when SBOMs are integrated with a vulnerability intelligence feed and ideally with the organization’s existing vulnerability management tooling. The SBOM tells you what’s in the software. The feed tells you which of those components have known issues. The combination tells you where to act first.

Supply Chain Risk Management

SBOMs also support supply chain risk analysis in a way that vendor questionnaires and attestations alone cannot. If a third-party component in a vendor’s product traces back to a country of concern, a known risky maintainer, or an abandoned open-source project with no active maintenance, the SBOM surfaces that. Without it, that dependency is opaque.

This matters for SCRM programs aligned to NIST SP 800-161r1 and for organizations operating under Executive Order 13873 or similar directives. It also matters practically: software that looks clean on the surface can carry significant supply chain risk embedded two or three dependency layers deep.

License Compliance and Lifecycle Management

License tracking is often underappreciated as an operational SBOM use case. Open-source components carry licensing terms—some permissive, some restrictive. GPL-licensed components, for example, can impose copyleft obligations on the software incorporating them. Legal and contracting teams increasingly want to know what open-source components are embedded in government software—both for compliance and for future procurement flexibility.

Beyond licensing, SBOMs support lifecycle planning. End-of-life components that no longer receive security patches represent ongoing risk. SBOMs make those components visible, which allows engineering and program management teams to prioritize modernization before that risk becomes an incident.

SBOM Formats, Standards, and the Policy Landscape

Two formats dominate the current SBOM landscape: SPDX (Software Package Data Exchange), developed under the Linux Foundation and published as ISO/IEC 5962:2021, and CycloneDX, an OWASP project purpose-built for security use cases. Both are machine-readable, both are open standards, and both are referenced in federal guidance. The practical differences between them matter less than ensuring the format is actually machine-parseable and contains the required minimum elements.

CISA’s minimum elements guidance—published under the NTIA framework—defines the baseline data fields that must be present for an SBOM to be operationally useful. Organizations procuring software should evaluate vendor-provided SBOMs against those criteria before accepting them as compliant. A PDF listing component names doesn’t meet the bar. A structured SPDX or CycloneDX document with proper identifiers does.

The policy landscape has moved faster than implementation maturity in many sectors. EO 14028 created the mandate. OMB M-22-18 operationalized it for federal procurement. OMB M-23-16 extended the timeline while maintaining the requirement. CISA has continued publishing sector-specific guidance and tooling resources to help agencies close the gap. DoD is working through how SBOM requirements integrate with existing acquisition frameworks and ATO processes—that work is ongoing and evolving.

Where Implementation Gets Complicated

The SBOM concept is straightforward. The operational reality of building a mature SBOM program inside a federal organization is considerably messier. A few friction points come up consistently.

Vendor compliance is inconsistent. Federal policy requires agencies to collect SBOMs from software vendors. But large portions of the commercial software market—particularly established enterprise software providers with long-standing government contracts—are still not producing SBOMs that meet minimum element requirements. Procurement teams are in the uncomfortable position of enforcing requirements that vendor base hasn’t uniformly met. That tension doesn’t resolve quickly.

Consuming SBOMs requires tooling and process. Receiving an SBOM is one thing. Ingesting it into a workflow that actually surfaces actionable intelligence is another. Organizations need tooling that can parse SPDX or CycloneDX formats, correlate component identifiers against vulnerability feeds, and produce meaningful output for vulnerability management and remediation teams. That capability doesn’t exist natively in most organizations and requires deliberate investment to build.

SBOMs go stale quickly. Software changes frequently. An SBOM generated at build time reflects the state of the software at that moment—not six months later after a dependency update. Organizations need processes that ensure SBOMs are regenerated with each meaningful release and that the SBOMs on file correspond to what’s actually running in production. Without that discipline, an SBOM collection program provides false confidence.

Legacy software is largely unaddressed. Most SBOM policy and tooling assumes software built with modern development practices—CI/CD pipelines, package managers, version-controlled dependencies. Legacy systems, custom applications built years ago, and embedded software in operational technology environments often don’t fit that model. Generating a useful SBOM for a legacy system may require significant manual effort or specialized tooling, and in some cases it may not be feasible at all without rebuilding significant portions of the development record.

Staffing and process gaps are real. SBOM programs require ownership. Someone has to manage the collection process, validate incoming SBOMs, maintain the inventory, and operationalize the data into vulnerability management workflows. That’s not a trivial staffing investment, and many organizations haven’t fully budgeted for it. The risk is that SBOM collection becomes a box-checking exercise rather than an operational program.

Common Mistakes

Treating SBOM collection as a compliance artifact rather than an operational tool. Organizations that collect SBOMs purely to satisfy procurement requirements—and then store them without integrating them into vulnerability management or incident response processes—are missing the actual value. An SBOM sitting in a document repository helps no one during an incident.

Accepting non-conforming SBOMs from vendors. Vendors sometimes provide documentation that looks like an SBOM but doesn’t meet minimum element requirements. Human-readable PDFs, partial component lists, and spreadsheets without proper identifiers don’t satisfy the operational or policy requirements. Procurement teams need clear acceptance criteria and the technical ability to evaluate what they’re receiving.

Ignoring transitive dependencies. An SBOM that only captures first-level dependencies misses a significant portion of risk. Most software vulnerabilities in the post-Log4Shell landscape have surfaced in nested, transitive dependencies—libraries that other libraries depend on. An SBOM program that doesn’t surface those provides incomplete coverage.

Failing to establish an SBOM freshness standard. Accepting a single SBOM at the time of initial procurement—and then never updating it—creates a rapidly degrading picture of actual software composition. Policy language matters here: contracts should specify SBOM delivery with each major and minor software release, not just at initial delivery.

Underinvesting in the consumption layer. Organizations spend energy on collection and policy but don’t invest in the tooling and processes needed to actually use SBOM data. The collection side is relatively straightforward. The analysis, correlation, and workflow integration side is where the operational value is—and where most programs fall short.

Recommended Federal Approach

Start with policy alignment. Ensure your procurement language explicitly requires SBOMs conforming to NTIA minimum elements in SPDX or CycloneDX format. Make the acceptance criteria specific—format, fields required, delivery timing, and update cadence. Vague language produces vague compliance.

Build the consumption capability alongside collection. Identify tooling that can ingest SPDX and CycloneDX formats and correlate component identifiers against NVD or other vulnerability intelligence feeds. Define the workflow that connects SBOM analysis output to your existing vulnerability management process. That connection is where the operational value lives.

Establish a freshness standard and enforce it. Require SBOM updates with each software release. Build verification into your patch and update workflows so you’re not operating on stale inventory data. An outdated SBOM may be worse than no SBOM—it gives false confidence that the data is current when it isn’t.

Scope your in-house software development. If your organization develops or customizes software, generate SBOMs from your own build pipelines. Modern CI/CD tooling supports SBOM generation natively or through integrated tooling. Don’t apply SBOM requirements only to vendor software while leaving your own custom applications undocumented.

Address legacy systems deliberately. Identify which legacy systems in your portfolio represent the highest risk and prioritize SBOM development for those environments. Where automated generation isn’t feasible, manual component documentation is better than no documentation at all—it just needs to be maintained with the same discipline.

Assign ownership. An SBOM program without a named owner with authority, resources, and clear responsibilities doesn’t sustain itself. Someone has to run this as an operational program—not as a side task. That resource investment is what separates organizations with meaningful software transparency from those who have a folder full of PDF documents they can’t actually use.

For organizations building out a broader software supply chain security posture, continuous monitoring capabilities are a natural complement to SBOM programs—providing the ongoing visibility needed to detect changes and vulnerabilities as they emerge rather than only at point-in-time assessment. Understanding the full scope of what’s running in your environment is foundational to that posture, and SBOMs are where that understanding starts.