The U.S. Office of Management and Budget (OMB)'s decision to rescind M-22-18 and M-23-16 and replace them with M-26-05 has been framed as a win for flexibility and a rollback of security theater. That framing is not entirely wrong, but it misses something fundamental about how modern software actually fails. There are pieces of this shift that are directionally correct, and others that risk undoing what little consistency the federal software ecosystem had finally begun to build.
Software Security Shouldn't Be a Compliance Checkbox
Let's start with the part they got right. The critique of one-size-fits-all security is fair. There was never a single universal method that could meaningfully validate software security across every agency, every system, and every risk profile. M-26-05 explicitly acknowledges this by pushing agencies toward risk-based validation instead of a single government-wide attestation requirement. That instinct makes sense.
Attestations were never the finish line, and treating them as such confused activity with outcomes. A signed statement saying an organization follows secure development practices does not prevent a compromised build pipeline, a poisoned dependency, or a swapped artifact that no one notices until it is too late. Paperwork has never stopped real-world supply chain attacks. Security comes from evidence, not declarations. Moving away from point-in-time checkboxes is a reasonable correction.
The memo also points in a better direction when it comes to software bills of materials (SBOMs). Allowing agencies to request current SBOMs, including SBOMs that reflect the runtime production environment for cloud platforms, is an improvement over static paperwork generated once and forgotten. An SBOM that represents what is actually running is far more useful than one frozen at the moment someone checked a compliance box and moved on.
Removing the Baseline Creates More Risk, Not Less
But this is where the optimism has to stop. Rescinding the existing memos outright removes the only shared baseline that agencies and vendors had. Minimum bars are not about wanting more bureaucracy. They create consistency across a fragmented ecosystem. When you remove that floor without replacing it with a stronger, clearer model for evidence of security, the result is not less friction. You get more ambiguity. Vendors are left guessing which agencies will accept what. Agencies reinvent validation approaches independently. Costs go up, expectations diverge, and security slowly degrades in the gaps between interpretations.
Risk-based approaches only work when there is agreement on what acceptable evidence looks like. Without that shared understanding, risk-based becomes shorthand for unclear, uneven, and unenforced.
The same problem shows up in the idea of security evidence being provided on request. On-request validation is still reactive. By the time someone asks for proof, the software is already built, deployed, and often widely consumed. Modern software supply chains move too quickly for after-the-fact reviews to meaningfully reduce risk. Security has to live where software is created, not where it is audited.
Risk-Based Security Still Needs Shared Expectations
Which leads to the practical takeaway. If the goal is to move away from security theater, that is the right goal. But removing paperwork is not the same thing as improving security. The only approach that scales is one that measures outcomes instead of forms. That means continuous evidence rather than point-in-time attestations. It means controls embedded directly into how developers work, in pipelines and repositories, not bolted on later through audits. It means understanding risk at the component level so agencies can focus on what is actually exploitable instead of drowning in compliance noise.
The software supply chain is already moving faster than policy. It always will. The answer is not fewer requirements without a replacement. The answer is automated, evidence-driven assurance that is part of how software is built and consumed, not a PDF filed after the fact.
Tags
Comply with SBOM Regulations
Meet regulatory requirements with Sonatype SBOM Manager – a single solution for SBOM monitoring, management, and compliance.