Why SBOMs Matter for Federal Cybersecurity

Supply chain risk used to be an abstract concern in federal cybersecurity conversations. It showed up in risk registers, got acknowledged in assessments, and then often sat unresolved because no one had a clean answer for how to actually measure it. That changed fast. Between high-profile software supply chain compromises, escalating third-party vendor incidents, and a wave of executive-level policy mandates, federal agencies are now being asked to demonstrate something they have rarely been required to prove: a concrete, verifiable accounting of what software is actually running in their environments and what components that software is built from.

That requirement has a name. A software bill of materials, or SBOM, is a structured, machine-readable inventory of the components, libraries, and dependencies that make up a software product. It is not a new concept in software development. What is new is the federal government treating SBOMs as a security and procurement requirement rather than a development artifact. The shift is significant, and it has implications for how agencies manage software procurement, how contractors build and deliver software, and how security teams respond when a vulnerability is disclosed in a widely-used open-source library.

Most agencies are somewhere in the middle of figuring this out. They have guidance. They have policy pressure. What they often lack is a clear operational picture of how SBOM requirements connect to existing workflows, who owns SBOM ingestion and analysis, and how findings from SBOM data translate into actionable risk decisions. This article addresses those gaps directly, from why the policy push happened to how agencies can build a sustainable SBOM practice that actually supports mission outcomes.

The stakes are not theoretical. When a critical vulnerability is discovered in a widely-deployed software component, agencies without SBOM data spend days or weeks manually inventorying which systems are affected. Agencies with functional SBOM programs can answer that question in hours. That difference matters operationally, and it matters even more during an active incident.

Understanding why SBOMs became a federal requirement, what the operational challenges look like in practice, and how to build toward a mature posture is increasingly essential for anyone supporting federal IT, cybersecurity, or acquisition functions.

EO 14028 and the Federal SBOM Mandate

Executive Order 14028, signed in May 2021, is the policy document that formalized SBOM requirements in the federal space. Titled “Improving the Nation’s Cybersecurity,” the order was issued in direct response to a series of significant software supply chain incidents that exposed how deeply software component risk had been underestimated across both government and commercial environments. Section 4 of the order specifically directed the National Institute of Standards and Technology to publish guidance on critical software and software supply chain security, and it explicitly named the software bill of materials as a required element of software security transparency.

NIST followed with guidance documents and CISA published minimum element recommendations for SBOMs, establishing what fields are required, what formats are acceptable, and what operational use cases SBOMs are expected to support. The accepted machine-readable formats in the federal context are currently CycloneDX and SPDX, both of which support automated ingestion and tooling integration. These are not suggestions. When agencies and contractors engage around SBOM delivery, format compliance matters because an SBOM delivered in an incompatible or non-machine-readable format provides limited practical value for automated analysis.

The policy trajectory since EO 14028 has moved in one direction. CISA has continued expanding SBOM guidance. OMB has issued memos reinforcing software supply chain security requirements. Proposed and enacted acquisition regulations have begun incorporating SBOM-related language into federal contract requirements, particularly for software used in national security systems and critical infrastructure. Contractors who build and deliver software to federal agencies increasingly face SBOM delivery as a contractual obligation, not an optional enhancement.

For agencies, this creates a two-sided problem. On one side, they must manage their own internal software inventories and build the capability to ingest, store, and analyze SBOM data from vendors and contractors. On the other side, they must define what they actually require in contract language, procurement vehicles, and delivery acceptance criteria. Neither side is trivial. Many agencies are still working through what SBOM acceptance and review processes should look like operationally, which personnel own them, and how they connect to existing security authorization workflows.

The compliance framing matters, but it is worth being clear about what EO 14028 actually changed. It created accountability. It gave policy teeth to what security practitioners had been saying for years about software component visibility. But compliance with SBOM requirements and operational use of SBOM data are two different things, and agencies that treat SBOMs purely as a documentation checkbox will not realize the security benefit that justified the requirement in the first place.

SBOMs as a Supply Chain Risk Tool

The supply chain risk problem that SBOMs are designed to address is not hypothetical. Modern software is almost never built from scratch. Commercial products, government-developed systems, contractor-delivered applications, and open-source tools all share a common characteristic: they are assembled from components. Those components include open-source libraries, proprietary modules, third-party frameworks, runtime dependencies, and embedded utilities that may themselves contain nested dependencies. The actual build graph of a moderately complex software application can include hundreds or thousands of distinct components, each maintained by a different entity, each carrying its own vulnerability history and update cadence.

The operational security problem this creates is specific. When a vulnerability is disclosed in a widely-used component, whether a logging library, a cryptographic module, or a network parsing utility, every organization running software that depends on that component is potentially exposed. The challenge is that most organizations have no reliable way to determine which of their systems are affected without SBOM data. In a federal environment with dozens or hundreds of authorized systems, that assessment process is often manual, time-consuming, and incomplete.

A functional software bill of materials (SBOM) program inverts that problem. When vulnerability disclosures occur, security teams can query their SBOM repository to identify which authorized systems contain the affected component version, prioritize response based on system criticality and mission impact, and coordinate patching or mitigating controls from a position of actual knowledge rather than inventory uncertainty. That is a measurable operational improvement, and it is the core security justification for SBOM investment beyond compliance.

Supply chain risk extends beyond vulnerabilities in open-source libraries. It also includes counterfeit or tampered components, software from vendors with inadequate development security practices, components sourced from jurisdictions with adversarial interests, and products that contain undisclosed third-party software. SBOM data, particularly when combined with attestation and provenance information, supports analysis across all of these dimensions. An SBOM that includes component origin, version, license data, and cryptographic hashes gives federal security teams a starting point for evaluating whether software components meet organizational risk tolerance before deployment.

Where SBOMs Fit in the Broader Supply Chain Security Architecture

SBOM is one layer in a broader software supply chain security posture that also includes vendor risk assessments, secure development attestations, software composition analysis tooling, and authorized software repositories. None of these elements replace the others. SBOMs provide the component inventory layer. Vendor attestations address the development process layer. Composition analysis tools provide the automated scanning layer. Together, they give agencies a defensible picture of what is running, where it came from, and whether it meets current security standards.

Federal procurement is where this architecture either comes together or falls apart. If SBOM delivery is not defined as a contract requirement with clear format standards, delivery timelines, and update cadences, agencies will receive inconsistent data that is difficult to use at scale. Building SBOM requirements into acquisition strategy, contract templates, and vendor acceptance criteria is foundational work that pays dividends well after contract award.

Operational Realities of Federal SBOM Implementation

The policy case for SBOMs is straightforward. The implementation reality is considerably more complicated, and the gap between the two is where most federal programs are currently operating. Understanding what actually makes SBOM programs difficult to stand up and sustain is essential for planning realistic timelines and resource allocations.

Ownership is the first problem. In most federal organizations, no single team has clear responsibility for SBOM collection, ingestion, and analysis. Software delivery often involves program managers, contracting officers, systems engineers, and security teams, none of whom may have defined roles for SBOM handling. Without clear ownership, SBOMs get delivered, filed, and never actioned. The security value disappears because no one has the mandate or tooling to do anything with the data after it arrives.

Tooling is the second problem. Ingesting and analyzing SBOM data at scale requires tooling that integrates with vulnerability databases, tracks component versions across multiple authorized systems, and surfaces risk findings in formats that security teams can act on. Many agencies are still evaluating tooling options or running pilots. The commercial and open-source tooling ecosystem for SBOMs has matured significantly since 2021, but federal procurement and authorization timelines mean that many programs are still in early stages of deploying approved tooling.

Legacy software is the third problem, and arguably the most persistent. A substantial portion of federal IT infrastructure runs on software that predates modern SBOM practices. These systems may run on unsupported platforms, have no vendor providing updated SBOMs, or contain components whose provenance is genuinely unknown. For these systems, agencies typically need to generate SBOMs through software composition analysis tooling, binary analysis, or manual documentation efforts, each of which is resource-intensive and produces results of varying completeness and accuracy.

Vendor Consistency and Contractor Compliance

Even for modern software under active development, SBOM delivery quality from vendors and contractors is highly variable. Some vendors have mature SBOM generation pipelines integrated into their CI/CD processes and can deliver accurate, updated SBOMs with each software release. Others are still building that capability. A contractor who is contractually obligated to deliver an SBOM but has no internal tooling to generate one will produce a document that meets the letter of the requirement while providing limited operational value.

Agencies that have invested in SBOM programs report that vendor education, clear contract specifications, and pre-delivery SBOM reviews dramatically improve data quality over time. The first SBOM delivery from a new contractor is rarely the most complete. Establishing feedback loops, defining acceptance criteria clearly, and treating SBOM quality as an ongoing program management concern rather than a one-time delivery event produces materially better outcomes.

The RMF connection also needs explicit attention. SBOMs should be integrated into system authorization packages, particularly in the system inventory and supply chain risk management components of the security plan. SBOM data should inform control assessments related to component inventory, vulnerability scanning, and supply chain risk management controls. When SBOMs exist in isolation from the authorization record, they provide incomplete value and represent a missed opportunity to strengthen the authorization posture of the system.

SBOM Maturity Comparison: Reactive vs. Integrated

The table below illustrates the practical operational difference between federal programs that treat SBOMs reactively and those that integrate SBOM data into routine security workflows. Most agencies currently fall somewhere in the middle, with pockets of maturity and significant gaps in coverage.

Common Mistakes

The most common mistake in federal SBOM programs is treating SBOM delivery as a compliance checkbox rather than a security workflow input. An agency that receives SBOMs from contractors, stores them in a shared drive, and considers the requirement satisfied has done the minimum work while realizing none of the operational benefit. The security value of SBOM data exists only when that data is queryable, current, and connected to vulnerability management processes. A static document filed at contract close is not an operational SBOM program.

A closely related mistake is accepting SBOMs in non-machine-readable formats. PDF or Word document SBOMs satisfy a surface-level contractual requirement but cannot be ingested into tooling, queried programmatically, or compared against vulnerability databases at scale. Agencies that do not specify machine-readable format requirements in contract language will routinely receive documents that cannot be used for their primary security purpose. This is preventable, but it requires explicit language in acquisition documents before contract award.

Treating SBOMs as a one-time artifact rather than a living document is another persistent error. Software changes. Dependencies get updated. New vulnerabilities are discovered in components that appeared clean at initial delivery. An SBOM that accurately reflected a software product at contract award may be significantly inaccurate six months later if the vendor has released updates without delivering corresponding SBOM revisions. SBOM refresh requirements need to be built into contract language and program management processes from the start.

Excluding legacy systems from SBOM programs entirely is understandable given the complexity involved, but it creates a significant blind spot. Legacy systems are often the highest-risk components of a federal environment precisely because they are running unpatched, unsupported software with unknown component histories. Documenting the gap, conducting best-effort composition analysis, and managing legacy SBOM coverage as a risk item with a mitigation plan is a more defensible posture than simply excluding those systems from scope.

Finally, standing up SBOM programs without addressing the staffing and ownership question almost always results in programs that stall after initial implementation. Someone needs to own SBOM ingestion, review, quality assurance, vendor follow-up, and integration with vulnerability management. If that responsibility is distributed across teams without clear accountability, the program will degrade over time as competing priorities pull attention elsewhere. SBOM programs that survive and mature have designated ownership, not shared ambiguity.

Recommended Federal Approach

A practical federal SBOM program starts with governance before tooling. Before deploying any SBOM management platform, agencies should define what an SBOM is expected to accomplish in their specific operational context, who owns each step of the lifecycle, and how SBOM findings connect to existing security workflows. That governance work is not glamorous, but it is the difference between a program that sustains itself and one that produces data that no one uses.

Acquisition integration should be addressed in parallel. Contracting officers and program managers need SBOM clause language ready for incorporation into new awards and, where possible, into modifications to existing contracts. That language should specify format requirements by name, delivery triggers tied to software releases, completeness expectations based on CISA minimum element guidance, and acceptance criteria that give the agency grounds to reject SBOM deliveries that do not meet standards. Building a library of reusable contract language for SBOM requirements reduces the burden on individual program teams and ensures consistency across the portfolio.

For the security team, the priority is connecting SBOM data to vulnerability management as quickly as possible. Even before a full SBOM repository is operational, establishing a process for manually correlating SBOM component data against high-priority CVEs builds organizational muscle and demonstrates security value. Automating that process over time through tooling integration is the maturity path, but the workflow needs to exist before the tooling can support it effectively.

RMF practitioners should review how SBOM data maps to relevant NIST SP 800-53 controls, particularly in the supply chain risk management (SR) control family and the system and information integrity (SI) family. SBOM data directly supports control implementation for component inventory, software integrity verification, and supply chain event monitoring. Documenting that mapping makes SBOM investment visible in authorization packages and supports auditor and assessor understanding of how the agency is implementing supply chain risk management in practice.

For legacy systems, the recommended approach is structured triage. Categorize legacy software by mission criticality and risk profile. For the highest-risk legacy systems, invest in software composition analysis to generate best-effort SBOMs and document known gaps. For lower-criticality legacy software, document the gap, assess compensating controls, and build SBOM generation into any upcoming refresh or modernization effort. Managing legacy SBOM coverage as a risk register item with active tracking is more defensible than treating it as out of scope.

Agencies that are looking for a structured entry point to this work should start by reviewing the available federal technology solutions and building internal alignment around what SBOM program maturity looks like for their specific environment, mission, and resource constraints. Maturity does not require perfection on day one. It requires a defensible starting point, clear ownership, and a plan to expand coverage over time as tooling, staffing, and procurement cycles allow.

The federal agencies that will fare best when the next significant supply chain vulnerability event occurs are the ones that have invested now in building SBOM programs that are operational, not just documented. The compliance mandate created the requirement. Operational investment determines whether that requirement translates into actual security resilience. For federal cybersecurity programs under sustained supply chain pressure, that distinction is the one that matters most. Learn more about how Anchor Defense approaches federal technology and security resources to support mission-driven organizations at every stage of program maturity.