Summary

  • In GAO-26-107530, senior officials at 17 of 24 federal agencies reported that OMB and NIST guidance created conflicting expectations for software bill of materials (SBOM) collection and storage. The finding is about agency-reported procurement friction, not a count of breaches or unsafe products.
  • GAO contrasted the older OMB M-22-18 approach, which treated SBOM collection as optional and the list as a static artifact, with NIST's emphasis on release-level component data usable for vulnerability management. OMB rescinded M-22-18 in January 2026; M-26-05 lets agencies require a current SBOM by contract on request while keeping agency heads responsible for software and hardware security.
  • GAO recommended additional Cybersecurity and Infrastructure Security Agency (CISA) guidance on how agencies generate, receive, analyze and use SBOM data in purchasing, development and risk management. The public test is an implementation path from current component evidence to an owned security action, not another unopened form.

The same list has two possible lives

An SBOM names the components inside a software release. Procurement can collect it as evidence that a supplier supplied a document. Security can use the component data to ask whether a newly reported vulnerability touches software the agency actually runs. Those are different workflows. One ends when the file is accepted; the other starts when the file's contents can be matched to a running system, a version and a risk decision.

GAO's June 23, 2026 report on cloud procurement found the gap across agencies. Officials from 17 of 24 selected agencies said OMB and NIST software guidance conflicted and made SBOM collection and storage harder. This was a set of interviews about acquisition practice, not a security-incident count. The report separately found 17 agencies reporting cloud-cost problems. The identical number describes a different question and should not be folded into the SBOM finding.

The older GAO account in the full report identifies three points of friction. OMB's M-22-18 treated collection as optional, while NIST encouraged software producers to track and share component data for each release. OMB assigned agencies the job of building collection processes, while NIST pointed to producer-supplied data in standard formats. OMB treated the list as a compliance artifact; NIST described data that could feed vulnerability scanning and risk management. A federal buyer trying to write one contract and one internal process could reasonably ask which of these jobs it was being ordered to perform.

That split had operational costs even without an incident. Five agencies told GAO that varied forms and procedures across agencies would burden producers serving more than one buyer. Five reported difficulty getting SBOM information from software producers, including when a reseller stood between the agency and the producer. These groups may overlap; the audit does not present them as ten separate agencies. Each example points to the same missing handoff: no shared answer about who produces the data, in what form, on what version, and who can obtain it when the software is in use.

January changed the memo, not the work

OMB's M-26-05 memorandum of January 23, 2026 rescinded M-22-18 and its companion M-23-16. The old memo is therefore history, not the current command. The newer policy puts responsibility for software and hardware security on each agency head, continues to require complete inventories and risk-based processes, and allows an agency to choose contract terms requiring a current SBOM on request. For a cloud platform, such a term should specify the runtime production environment.

This is a real change in authority. A central collection recipe has given way to a choice at each agency's contract desk. The choice may allow a buyer to match its evidence demand to the software it runs. It also makes the agency responsible for deciding when the list matters, who can request it and whether the resulting data can be used. GAO said the January memo clarified responsibilities but left the practical challenges unresolved. An optional artifact does little for vulnerability response if the contract lacks a timely delivery term or the receiving team cannot process the data.

NIST's supply-chain guidance treats component information as part of software security work. CISA's September 2025 shared-vision paper says generation, consumption and analysis should be integrated into existing risk-management and development practices. GAO found that this vision still did not tell agencies specifically how to connect data to their tools and processes. A principle can tell an institution what a useful list is for; procurement officers and operators need to know how it crosses their desks.

The missing bridge has an owner

GAO recommended that the Department of Homeland Security direct CISA to issue additional implementation guidance. It called for instructions that address SBOM generation, consumption and analysis in risk management, purchasing and software development, using tools where appropriate. DHS agreed. Its response projected a September 30, 2026 completion date for guidance work. That date is a promise in a response, not evidence of an issued final instrument. GAO's public recommendation entry was still marked open when checked for this article.

The governance question is sharper than whether every agency can collect a PDF. A useful chain needs a producer to identify the release or live cloud environment, a contract that gives the agency timely access, a machine-readable format the buyer can process, a route into vulnerability and license analysis, and a named operator who decides what to do when a component changes. OMB controls the agency policy choice; NIST describes technical practice; CISA has been assigned the implementation bridge. Their texts need to meet at the actual handoff.

The next official CISA guidance that spells out those handoffs, together with agency processes or contracts showing current SBOM data arriving and being used, would change the judgment. GAO has already supplied the problem statement: 17 agencies told the auditor that two sets of instructions rubbed against one another. A parts list earns its place in government when it can move from a purchasing file to the person who must act on a vulnerable part.

Sources