SBOM Attestation Acceptance in Enterprise Procurement

M-26-05 rescinded M-22-18 and M-23-16, the two memos that had required standardized attestation across federal civilian agencies. OMB's stated reasoning was that the prior approach "prioritized compliance over genuine security investments," pulled agencies away from building requirements tailored to their own risk profile, and never accounted for hardware-level threats in the first place. EO 14306, signed in June 2025, had already softened the ground by amending EO 13694 and EO 14144 to strip out enhanced attestation mandates, even while keeping software supply chain security nominally on the priority list.

None of that touches the requirements sitting outside the rescinded memos, and vendors who read the rollback as a general reprieve are misreading it. The FDA's medical device SBOM requirement has been in effect since March 2023, with full enforcement authority active since that October, and nothing in M-26-05 changes it. The Army issued its own SBOM policy in early 2025, operating under a separate authority from the civilian OMB framework. CISA's Repository for Software Attestation and Artifacts still carries the implicit expectation that an SBOM is the primary artifact agencies will ask for, even without a mandatory form behind it.

One defense agency went the opposite direction from the discretionary language coming out of OMB. A July 2025 directive from the Secretary of Defense states that DoD will not procure hardware or software susceptible to adversarial foreign influence that presents risk to mission accomplishment. That's a harder line than anything in M-26-05, and it signals that at least one major federal buyer isn't waiting around for a universal standard before it enforces its own.

Outside the country, the requirements are piling up rather than easing off. The EU's Cyber Resilience Act entered into force in December 2024, with vulnerability and incident reporting obligations starting September 2026 and the broader compliance requirements landing in December 2027. Germany's BSI TR-03183-2 already spells out concrete SBOM format and content rules aligned with the CRA, affecting any manufacturer selling into the EU or bidding on German federal contracts. NIS2's implementing regulation requires essential and important entities, spanning healthcare, financial services, energy, and infrastructure, to report on the hardware and software components they use, which functions as a de facto transparency mandate for any B2B software vendor serving those sectors. PCI DSS 4.0 assessors are already asking for component inventories during 2025 and 2026 assessments, and a one-time static list no longer satisfies what the standard actually wants. India's CERT-In released its own SBOM guidelines in July 2025, recommended for government and public sector buyers and pushed toward BFSI and fintech as essential services, with procurement contracts expected to spell out data elements, delivery timing, and delivery method. The EU Machinery Regulation, effective January 2027, will require manufacturers to identify all safety-critical software in a machine and make that information accessible at all times, an implicit SBOM obligation dressed up in different language.

A vendor selling into two or three of these markets at once is facing a matrix of overlapping, non-identical requirements that the Common Form had briefly promised to simplify. That promise is gone, and it isn't coming back in this form. The fragmentation is the new baseline, and anyone still waiting for a single federal standard to settle the question is planning around a document that no longer exists.

What buyers are actually asking for when they evaluate SBOM attestation

The floor moved this year, and it's worth being precise about where it landed. The original NTIA minimum elements from 2021, the seven fields most vendors have treated as gospel (supplier name, component name, version, other unique identifiers like purl or CPE, dependency relationships, author of the SBOM data, and a timestamp), were formally replaced on July 29, 2026, by the CISA 2026 Minimum Elements. That update adds component hash, license information, tool name, and generation context. None of this creates a new legal requirement on its own, but sophisticated buyers had already started writing the expanded field list into RFPs well before CISA made it official.

Format is largely settled, and arguing about it wastes time better spent elsewhere. CycloneDX, standardized through OWASP and now formalized as ECMA-424, and SPDX, an ISO/IEC standard under 5962, are both accepted across essentially every framework in play. What buyers want isn't a preference for one over the other, but tooling flexible enough to emit either, since different customers and different regulators may specify different formats for the same product. CycloneDX has the edge for vendors carrying cryptographic or AI-embedded components: it's had native CBOM support since version 1.6, alongside AI/ML-BOM types that matter more each quarter.

The real shift in buyer behavior is about staleness, and this is where most vendors are still getting it wrong. Most SBOMs generated today are produced once, at the end of a build, filed somewhere, and never touched again. Buyers who understand supply chain risk have started drawing a hard line between that kind of point-in-time artifact, produced by a workflow problem rather than an SBOM problem, and a living inventory regenerated with every release. Pairing an SBOM with VEX data, which tells a buyer whether a disclosed vulnerability is actually exploitable in the vendor's specific configuration rather than just theoretically present somewhere in the dependency tree, has become a real differentiator rather than a nice-to-have.

M-26-05 left one concrete technical requirement standing even as it removed the mandatory attestation framework: if an agency requires an SBOM from a cloud provider, that SBOM has to describe the runtime production environment, not a test environment and not a static software list compiled at build time. Evaluators are starting to ask, directly, whether the SBOM in front of them reflects what's actually running in production right now, and a vendor who can only produce a build-time snapshot is going to lose that conversation. CERT-In's guidelines push in the same direction from a different angle, calling for a detailed set of data fields including multi-tier dependency relationships and known vulnerabilities tagged by severity, and that level of granularity previews where global procurement standards are heading. Buyers who've internalized this now expect vendors to think carefully about what exploitability data is shared and with whom, rather than treating every SBOM as a document suitable for unrestricted publication.

Why build provenance has become a second, distinct acceptance criterion alongside the SBOM itself

An SBOM tells a buyer what components are in a piece of software. It says nothing about whether the build process that assembled those components was itself trustworthy, and two incidents made that distinction impossible to ignore.

The 2024 XZ Utils backdoor wasn't a malicious dependency sitting in a manifest waiting to be flagged. It was inserted directly into the build and release path, which means a component-level SBOM, no matter how complete, would never have caught it. Other attacks targeting package ecosystems have worked the same way, compromising trusted package publishing and CI/CD workflows rather than sneaking a bad package into a dependency list. Sonatype's tracking put the scale of the broader problem in stark terms: over 454,600 new malicious packages identified in 2025 alone, pushing the cumulative count past 1.2 million. Supply chain attacks surged globally over the same period, and over 70 percent of organizations reported at least one incident tied to third-party software.

Provenance, in operational terms, means cryptographic, tamper-evident proof that a given artifact came from a known source, went through a defined process, and was built on a system whose integrity can be verified. NIST has addressed this directly in guidance treating cryptographically signed attestations as a foundational piece of software integrity across the CI/CD pipeline, not an optional add-on. Procurement teams paying attention now look for SBOM enrichment that includes repository URLs, commit SHAs, in-toto attestations, and SLSA provenance records: the connective tissue that lets someone trace a binary all the way back to the source that produced it.

The standards already exist, and that's precisely why the excuse of "no clear framework" doesn't hold up anymore. In-toto, SLSA, OSV, and VEX all give vendors a way to make these claims without locking a buyer into a single vendor's proprietary format. What's actually missing is execution: industry observations consistently show that most organizations still struggle with the basics of implementing SLSA day to day, largely because modern CI/CD pipelines are sprawling, heavily automated, and stitched together from components with no clear boundary of identity and no reliable record of where any given artifact actually came from. Procurement questions are starting to reflect that gap directly. It's no longer enough to ask whether a vendor has an SBOM. The follow-up question, increasingly, is whether the vendor can prove the binary in front of the buyer actually matches what the SBOM describes, and that nothing tampered with the environment that built it.

How environment reproducibility connects to the credibility of an SBOM attestation

If the environment used to build software drifts even slightly between runs, two builds from identical source code can produce different artifacts. When that happens, an SBOM generated from one run doesn't necessarily describe what a second run, using the same source, would actually produce. The attestation becomes a snapshot of a single, potentially unrepeatable event rather than a durable description of the software, and most vendors have no idea this is even happening under their own build systems.

A study of more than five thousand Docker builds, published by Malka and colleagues in January 2026, found that only 6.4 percent of rebuilt images matched the original set of installed package versions exactly. Bitwise identity between builds was, for all practical purposes, never achieved. That one number captures the whole problem. An SBOM describing a build that can't be reconstructed is little more than an unverifiable artifact. It's a record of what one particular run happened to produce, with no guarantee the next run looks the same.

The Reproducible Builds project has spent years mapping exactly why this happens: tool versions, operating system assumptions, configuration files, file paths, locale settings, even time zones can all quietly change a build's output without anyone noticing. The Reproducibility Maturity Model, published by Siddiq and colleagues in November 2025, gives procurement teams a way to talk about this precisely. Lower maturity tiers reflect environments where build details are absent or only partially captured, while higher tiers require machine-readable, complete environment specifications, with the highest tiers pushing toward external, independent verification of the build environment.

Buyers in regulated sectors are starting to ask, in plain terms, where a vendor's build process sits on that scale. The practical answer for vendors who want to reach RMM-2 or RMM-3 without heroic manual effort is a Git-driven, declarative build environment, where every configuration change goes through review and every deployment can be reconstructed straight from version control, with no manual tweaks separating what passed testing from what's actually running. Tooling built on Nix, for instance, manages dependencies down to the package level in a way that makes this kind of reproducibility a structural property of the build rather than a discipline someone has to enforce by hand. That distinction matters: discipline erodes under deadline pressure, structure doesn't. When a procurement team asks for SLSA level 2 or higher, whether they use that exact phrase or not, they're really asking whether the build environment behind the SBOM can be trusted to produce the same thing twice.

The AI and ML component gap that most SBOM attestations do not yet address

An AI model embedded inside a product is a third-party dependency in every sense that matters to a security team, except that none of the standard scanning tools know how to read it. A component scanner built to parse package manifests has no way to inspect model weights, no way to trace training data lineage, and no way to evaluate the architecture decisions baked into the model itself.

An ML-BOM, sometimes called a Model BOM, is built to close that gap: it documents training data sources, architecture choices, safety benchmark results, and the provenance of the model artifact as a distinct object from the software wrapped around it. The tooling gap here isn't really a tooling gap at all, and vendors telling buyers "the format doesn't exist yet" are simply wrong. CycloneDX has had native CBOM support since version 1.6, and its schema has extended to address additional component types, so the format exists and is ready to use. What's missing is practice. Most companies shipping AI-enhanced products simply aren't generating this artifact, because almost nobody is asking for it yet, at least not formally.

That's about to change on a fixed timeline. The EU AI Act introduces its own requirements touching AI components, running alongside the CRA's SBOM requirements but addressing a genuinely different risk surface, which means vendors with AI embedded anywhere in their stack are facing two separate compliance tracks rather than one. Industry discussion has increasingly touched on large language models directly, and practitioners were candid about not knowing yet how to fit existing compliance frameworks around AI-generated or AI-assisted code and components. That uncertainty is real and shared across the industry. It isn't a sign any single vendor has fallen behind the pack.

For a vendor selling into healthcare, financial services, or government, where NIS2, the CRA, or FDA oversight already apply, handing a buyer an ML-BOM before it's formally demanded is a genuine edge, not a gesture. Most RFPs don't ask for it yet. The AI Act's timeline says that window won't stay open long, and vendors treating ML-BOM generation as optional today are going to be scrambling to retrofit it later.

How enterprise procurement teams are building their own acceptance criteria in the absence of a universal standard

No Common Form. Divergent sector mandates. Overlapping, non-identical international frameworks. That's the environment procurement teams are actually operating in now, and it means nobody can rely on a vendor checking a single federal box and calling the question closed.

What's emerging instead, informally but consistently, looks like a tier structure, and vendors who only clear the first tier are going to find themselves losing deals to competitors who cleared all four. The baseline tier asks for a machine-readable SBOM in CycloneDX or SPDX, covering every component including transitive dependencies, meeting the NTIA 2021 elements at minimum. The next tier is about currency: is the SBOM regenerated with every release, tied into vulnerability feeds, paired with VEX data that tells a buyer what's actually exploitable rather than just present. A third tier covers provenance and reproducibility directly, asking for in-toto or SLSA attestations, evidence that the build environment is version-controlled, and cryptographic signing on the artifacts themselves. A fourth tier is sector-specific: CBOM for organizations that need visibility into cryptographic assets ahead of post-quantum transitions, ML-BOM for anything with an embedded model, and a runtime production SBOM for cloud services, per the standard M-26-05 left in place.

CERT-In's framing captures where the most demanding buyers, across sectors and geographies, are already landing: an SBOM as a live operational feed, not a static document filed away after a single build. Procurement teams are converging on that posture regardless of what happened in the capital, which is the part vendors banking on the rollback keep missing. The rollback didn't lower the bar. It just took away the one form that used to tell vendors, in a single document, exactly where the bar was, and the bar itself only moved up.