COMMENTARY: Washington has spent years trying to improve federal software supply chain security with a familiar tool: paperwork.The instinct was right. After major supply chain shocks, the federal government wanted to push responsibility upstream—toward the companies that build and ship software—rather than leaving every agency, system owner, and taxpayer to absorb the cost of insecure defaults. That’s the backbone of Secure by Design: the industry should build security into products, not bolt them on after deployment.[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]But the mechanism the government leaned on—self-attestation—too often became a ritual. Suppliers promised on paper that they followed secure practices, agencies collected the forms, and defenders were left with the same operational problem when the next vulnerability hit: limited visibility into what was actually running.That's why the Office of Management and Budget’s (OMB’s) recent Memorandum M-26-05 represents an important course correction. It rescinds prior supply chain directives and shifts agencies to a risk-based approach that prioritizes outcomes over compliance theater. In plain terms: less emphasis on signatures and checklists, more emphasis on evidence.We’ll have to see whether this reset becomes consistent federal practice—or another well-intentioned policy that leaves uneven adoption and predictable seams for adversaries to exploit.Modern cybersecurity is an inventory problem before it's a remediation problem: we cannot fix what we cannot find.Recent incidents underscore the point. In March 2024, a sophisticated backdoor was discovered in certain versions of xz/liblzma after an attacker invested significant time building trust in the project before positioning malicious code upstream. In June 2024, the polyfill.io incident showed how attackers could use a widely-embedded dependency to serve altered JavaScript at scale, creating downstream risk for organizations that didn’t even realize they “owned” the problem.In both cases, defenders needed rapid, machine-speed answers: “Where is it?” and “What does it touch?” Paper promises don’t answer those questions.Trust based on assertion is fragile. At least we can test trust grounded in verifiable artifacts.The memo moves in this direction by pointing agencies to secure development frameworks and by letting agencies use contractual terms to require producers to offer a current SBOM when requested. The shift away from pure attestation and toward usable evidence represents a win for operators and a win for national security.Done right, this model shifts burden upstream, toward producers that are best positioned to know what's in their products, while giving agencies the ability to manage risk a machine speed.M-26-05 replaces paper promises with a better framework: risk-based decision-making grounded in evidence. That represents progress.But encouragement alone will not deliver consistent security across a federal enterprise that’s only as resilient as its least-visible dependency. If OMB wants this reset to matter, it should ensure that verifiable artifacts—SBOMs now, HBOMs where applicable—become routine for the systems where failure costs orgs the most.Rolling back cybersecurity theater makes sense. Now this administration needs to make sure it replaces it with something durable.Daniel Bardenstein, chief executive officer, Manifest Cyber, former chief of technology strategy, Cybersecurity and Infrastructure Security AgencySC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.
Why the old approach didn’t work
In the past, the government asked software producers to attest—often via signed PDFs—that they followed secure development practices. Paper assurances scale administratively. They do not scale operationally.A signed statement does not help an agency answer the questions that matter when an upstream incident lands on a Monday morning:- Where is the affected component deployed across my environment?
- What systems are exposed, and through which paths?
- What do we need to patch first based on exploitability and mission impact?
- What’s unsupported, end-of-life, or quietly changed since last week?
What M-26-05 gets right
M-26-05 reflects a more mature understanding of cybersecurity as an operational discipline. Instead of mandating one-size-fits-all checklists, it directs agencies to make risk-based decisions and emphasizes artifacts and practices that we can all validate and use.That’s the right direction. It’s also where Software Bills of Materials (SBOMs) and emerging Hardware Bills of Materials (HBOMs) matter—not because they magically make systems secure, but because they make security measurable.SBOMs are an inventory: a structured, machine-readable list of software components and dependencies. An HBOM extends the same logic into the physical layer: firmware, boards, and the components “software” actually runs on. These artifacts enable basic, non-negotiable questions every serious security organization must answer:- What do we run?
- What got exposed?
- What’s vulnerable?
- What’s unsupported?
- What changed since last week?
The problem: optional security becomes inconsistent security
The weakness in M-26-05 is not its intent. It’s the memo’s permissive posture.M-26-05 repeatedly relies on “may” language—agencies may use the prior resources; agencies may add contractual SBOM terms. Flexibility is understandable. Federal missions vary. A blunt, universal mandate can slow procurement, exclude non-traditional vendors, and create perverse incentives.But flexibility without a baseline turns into inconsistency. And inconsistency hands over a gift to attackers.Federal systems are interconnected. When agencies have uneven visibility into third-party components and supply-chain dependencies, coordinated vulnerability response becomes slower and less reliable. In mission-critical and national security contexts, uncertainty represents a risk, not a nuisance.A risk-based framework still needs consistent inputs. Without baseline evidence, “risk-based” becomes a slogan and a more sophisticated form of theater.How to make this policy stick
OMB does not need to reverse course. It needs to finish the job.Three moves would make M-26-05 operationally durable:- Make evidence a baseline for high-impact systems: Define when artifacts like SBOMs—and where appropriate HBOMs—are not optional: high-impact software, mission-critical systems, and national security-relevant procurements. Risk-based does not mean evidence-optional; it means evidence-calibrated.
- Set minimum quality and freshness expectations: Stale SBOMs are often worse than none because they create false confidence. Agencies need clear expectations for format, completeness, and update cadence so artifacts are operationally useful, not nominal.
- Enable consumption, not collection: Data that sits in a repository still represents paperwork—just in JSON. Shared services, automation, and validation tooling will determine whether this becomes a force multiplier for agencies or another compliance archive.
