How SBOMs Improve Software Procurement Decisions

Software procurement in federal environments has always carried risk. But for most of the past two decades, that risk was treated as something you managed after the fact, during assessments, audits, or incident response. The components inside a software package were largely opaque to the acquisition team signing the contract. You evaluated the vendor’s reputation, reviewed the documentation, checked the security controls, and moved forward. What was actually running under the hood remained someone else’s problem until it wasn’t.

That model has real limits. Supply chain compromises, end-of-life open source dependencies, and undisclosed third-party libraries have created situations where agencies inherited significant security debt at the moment of acquisition, before a single line of the contract was executed. The software was already encumbered by vulnerabilities that neither side fully understood. The agency absorbed the risk, and the mission paid the price.

A software bill of materials (SBOM) changes that dynamic by moving component-level transparency earlier in the lifecycle, into the procurement phase itself. When acquisition teams can examine the contents of a software product before signing, they gain the ability to evaluate risk before it becomes their responsibility to manage. That is a meaningful shift in how programs approach software risk and supplier accountability.

This article explains how SBOMs inform procurement decisions in practice, what questions they help acquisition teams answer, where the process breaks down, and what a realistic federal approach looks like given the budget, staffing, and timeline constraints that govern most programs.

The goal is not theoretical. Procurement teams are not analysts running academic exercises. They are operating under deadlines, working with incomplete information, and making decisions that will affect mission systems for years. SBOMs are a tool, not a solution on their own, and understanding how to use them well requires some operational honesty about what they can and cannot do.

What an SBOM Actually Tells a Procurement Team

An SBOM is a structured inventory of the software components that make up a product. It lists the libraries, frameworks, modules, and packages included in the build, along with version information and, depending on the format, licensing details and the relationships between components. Common formats include CycloneDX and SPDX, both of which are machine-readable and designed for automated analysis.

What that inventory actually tells a procurement team depends on how they use it. At the most basic level, it answers the question: what is in this software? That question sounds simple, but the answer is often surprising. Modern commercial software commonly pulls in hundreds of open source dependencies, some of which are well-maintained and some of which have not seen an active commit in years. A vendor may not have complete visibility into their own dependency tree unless they have invested in tooling to track it. An SBOM requirement during procurement forces that visibility to exist and to be disclosed.

Beyond the component list itself, an SBOM enables cross-referencing against vulnerability databases. When a procurement team or their supporting analysts ingest an SBOM and run it against sources like the National Vulnerability Database, they can identify whether any of the listed components carry known, active CVEs. That information is directly relevant to risk acceptance decisions. It can inform whether to proceed with a vendor, require remediation before delivery, or impose contractual obligations for patching timelines.

SBOMs also reveal licensing conditions that matter to federal programs. Open source components carry licenses with compliance obligations, and some licenses create legal constraints on how software can be used or distributed. Procurement teams supporting systems that redistribute software or integrate components into government-developed code have real legal exposure if licensing is not evaluated. An SBOM surfaces what needs to be reviewed.

What an SBOM does not tell you is whether the vendor’s development practices are sound, whether the software architecture introduces systemic risk, or whether the listed components are configured securely. It is one layer of information, and it is most useful when combined with other evaluation inputs such as vulnerability assessments, security architecture reviews, and supplier questionnaires.

Supply Chain Risk and the Procurement Window

Software supply chain risk is not a new problem, but the policy and operational focus on it has accelerated significantly since the executive-level attention that followed high-profile compromises of widely deployed commercial software. Federal agencies are now expected to understand not just the security posture of the software they acquire, but the integrity of the supply chain that produced it. That expectation is embedded in guidance from CISA, NIST, and the Office of Management and Budget, and it is increasingly reflected in agency acquisition strategies.

The procurement window is one of the few moments in a software lifecycle where the government has real leverage over a supplier. Before contract award, vendors are competing. They have incentive to demonstrate transparency and security maturity. After contract award, that leverage diminishes. The software is already in the environment, the program is operationally dependent on it, and switching costs make re-procurement politically and financially difficult. Requiring an SBOM as part of source selection is an exercise of leverage at the right time.

Supply chain risk in software procurement shows up in a few distinct ways. First, there is the upstream dependency risk: the components the vendor’s software relies on that were written and maintained by parties the vendor does not control. An outdated or abandoned library that handles authentication, cryptography, or network communication is a risk that travels with the product regardless of how well the vendor wrote their own code. Second, there is the provenance risk: uncertainty about whether the components in the delivered build actually match what is documented. Third, there is the ongoing maintenance risk: the question of whether the vendor will sustain the component stack after delivery or whether they will deliver a product with aging dependencies and no commitment to update them.

SBOMs address the first two directly. They surface dependency exposure and enable provenance verification when combined with build attestation requirements. The third risk, ongoing maintenance, requires contractual language that obligates the vendor to provide updated SBOMs at defined intervals or upon significant software releases. A one-time SBOM at procurement captures a point-in-time snapshot. It has limited value for long-term risk management unless there is a mechanism to keep it current.

Programs running on five-year contract vehicles need to think about what the component stack looks like three years after delivery. Components that are currently maintained become abandoned. Libraries that carry no CVEs today will carry them later. Building SBOM refresh cycles into contract performance requirements is what separates a procurement-time checkbox from a genuine supply chain risk management practice.

Embedding SBOM Requirements in Acquisition Language

Getting an SBOM into the procurement process requires deliberate action during acquisition planning. It does not happen by default. Contracting officers and program managers need to understand what they are asking for, why it matters, and how to structure the requirement so vendors can comply without creating unnecessary friction.

Where SBOM Requirements Belong in Acquisition Documents

SBOM requirements can appear in several places depending on the program’s acquisition structure. In a request for proposals, they can appear in the technical evaluation criteria or as a mandatory deliverable requirement. In a statement of work or statement of objectives, they can be specified as a performance requirement with defined format standards and delivery timelines. In contract data requirements lists, they can be identified as a formal deliverable with acceptance criteria. Each of these placements sends a different signal to vendors and creates different accountability structures.

For source selection purposes, the most impactful placement is in technical evaluation criteria. When vendors know that SBOM quality will be evaluated as part of their technical proposal, they are incentivized to invest in their internal processes before they submit. A vendor who produces a well-structured, complete SBOM with documented provenance is demonstrating a level of software development maturity that correlates with security posture. Vendors who cannot produce a coherent SBOM are telling you something important about how they manage their software internally.

Specifying Format and Minimum Content

Acquisition language should specify the SBOM format rather than leaving it to vendor discretion. Without format requirements, you will receive responses in incompatible structures that cannot be processed consistently. CycloneDX and SPDX are both well-supported and have been referenced in federal guidance. Either is workable; consistency across a program is more important than which format is selected.

Minimum content requirements should include component names, version numbers, package type, supplier or author identification, and a unique identifier for each component. Licensing information and dependency relationships add value if your evaluation process can consume them. CISA has published minimum element guidance for SBOMs that provides a reasonable baseline for what federal programs should require.

Ongoing delivery requirements should specify that updated SBOMs are required upon each major and minor release, and that vendors must notify the government when a component in the SBOM receives a critical or high severity CVE. That ongoing obligation is what keeps the SBOM useful after the initial delivery and transforms a procurement artifact into a living supply chain management tool.

Evaluating SBOM Submissions During Source Selection

Receiving an SBOM from a vendor is the beginning of the evaluation process, not the end. The document has value only if someone on the government side can analyze it and translate the results into procurement-relevant findings. That analysis step is where most programs currently struggle, and it is worth being direct about why.

Federal acquisition teams are not typically staffed with engineers whose job is to process SBOM files. Contracting officers, program managers, and even many ISSMs do not have the tooling or background to ingest a machine-readable SBOM and produce a risk summary. That gap is not a failure of the people involved; it reflects how procurement organizations have been resourced historically. But it is a real constraint that needs to be addressed before an SBOM requirement in acquisition language can produce actionable results.

The practical solution for most programs is to define a technical evaluation team or designate a supporting engineer whose responsibility includes SBOM analysis during source selection. That person, or that team, needs access to tooling that can ingest the SBOM format, cross-reference components against vulnerability databases, flag end-of-life or unmaintained packages, and produce a structured risk summary in terms that procurement decision makers can use. That tooling exists, and it does not require significant investment relative to what programs spend on source selection support overall.

When evaluating SBOM submissions, the questions that matter most for procurement decisions include: How many components carry active high or critical CVEs? Are any of those components in the software’s core attack surface, such as authentication handlers, network interfaces, or data processing pipelines? Are there components that are no longer actively maintained with no clear maintenance path? Are there licensing conditions that create legal risk for the intended use case? Does the SBOM reflect a build that matches the version being proposed, or is it generic documentation that was not generated from the actual product?

That last question matters more than it might initially seem. Vendors who produce SBOMs as a compliance artifact rather than an engineering output sometimes submit documents that do not accurately reflect what is actually in the delivered software. Post-award verification, either through independent analysis of the delivered build or through binary composition analysis, is the control that catches this problem. For high-impact systems, that verification step is worth the cost.

Common Mistakes in SBOM-Informed Procurement

The most common failure mode is requiring an SBOM without building the infrastructure to use it. This happens when procurement teams add SBOM language to acquisition documents in response to policy direction without thinking through who will analyze the results, with what tools, and against what criteria. Vendors submit SBOM files, contracting officers accept them as received, and the documents sit in a contract file without ever informing a procurement decision. The requirement was met technically and failed practically.

A related problem is treating SBOM submission as binary. Either the vendor provides a file or they do not. Programs that evaluate only whether an SBOM was submitted without evaluating its quality, accuracy, or completeness are not actually managing risk. They are checking a box. A vendor who submits an incomplete SBOM with incorrect version data and no CVE acknowledgment is not meaningfully more trustworthy than a vendor who submits nothing. The evaluation criteria need to assess substance, not just presence.

Procurement teams also sometimes frame SBOM evaluation too narrowly, focusing only on the current vulnerability profile without considering lifecycle sustainability. A component stack that carries no active CVEs today but is built on libraries that are approaching end-of-life creates future sustainment risk that will land on the program within the contract period of performance. Evaluating component maintenance trajectory is part of a complete risk picture.

Another mistake is requiring SBOMs as a one-time procurement artifact without building ongoing delivery obligations into the contract. Software changes after delivery. Dependencies are updated, new components are added, and vulnerabilities are discovered in components that were clean at the time of acquisition. A static SBOM that was accurate on award date tells you almost nothing about the risk profile of the software two years into a contract. Ongoing SBOM delivery is not optional if the goal is actual supply chain risk management.

Finally, programs sometimes apply SBOM requirements uniformly without calibrating the depth of analysis to the risk level of the system. A low-impact administrative tool and a high-impact operational system do not warrant the same level of SBOM scrutiny. The analysis investment should be proportional to the consequences of a supply chain compromise in that specific system. Risk-tiering the SBOM evaluation process makes the approach sustainable without creating bottlenecks in lower-stakes procurements.

Recommended Federal Approach

A practical federal approach to SBOM-informed procurement starts with policy alignment and ends with operational execution. The gap between those two points is where most programs lose traction, and bridging it requires a concrete operational model rather than a general commitment to transparency.

During acquisition planning, program offices should define the SBOM format requirement, the minimum content standard, the evaluation criteria, and the analysis support model before the solicitation goes out. If the program does not have organic SBOM analysis capability, that support needs to be identified in advance, whether through an existing support contract, an in-house engineering team, or a dedicated task order. The analysis support model should be ready before vendor responses arrive, not assembled after the fact.

During source selection, SBOM analysis should produce a structured risk summary for each vendor, covering vulnerability exposure, component lifecycle health, licensing risk, and an assessment of SBOM quality and accuracy. That summary should be available to the technical evaluation board as a formal input, not as informal background. Programs that want SBOM analysis to actually influence award decisions need to incorporate it into the formal evaluation record.

Contract terms should specify SBOM format, minimum content, delivery timing at each release, and notification obligations for newly discovered vulnerabilities affecting listed components. Programs with high-impact systems should include a post-award verification requirement that allows the government to confirm that the delivered software matches the SBOM documentation. That verification step is what gives the SBOM requirement real teeth and discourages vendors from treating it as a documentation exercise.

After award, the SBOM maintenance obligation should be tracked as a performance requirement. Program managers and ISSMs should have a defined process for reviewing updated SBOMs against the previous version to identify new components, changes in component versions, and emerging vulnerabilities. That process does not need to be elaborate, but it needs to exist and be executed consistently. Programs that require SBOMs but never review them after initial delivery have not reduced their supply chain risk; they have just created the appearance of managing it.

For programs that support enterprise or mission-critical environments, the SBOM program should be integrated with the broader software supply chain risk management framework, including the system’s RMF documentation, security assessment processes, and ongoing authorization activities. An SBOM that is disconnected from the authorization package is a missed opportunity to reduce the manual effort required during assessments and to provide authorizing officials with substantive evidence of component-level risk management.

The agencies and programs that are getting the most value from SBOM requirements are those that treated them as an operational practice from the beginning rather than a compliance artifact. They built the analysis capability before requiring the deliverable. They tied SBOM quality to evaluation scores. They used ongoing SBOM reviews as an early warning system for emerging vulnerabilities rather than waiting for a security advisory to arrive after the fact. That operational discipline is what makes the investment worthwhile, and it is accessible to programs of any size that are willing to build the process before the problem arrives. Learn more about federal technology resources that can support your program’s approach.