Recently, the White House Office of Management and Budget (OMB) announced that the agency is rolling back software security requirements.
The OMB has formally rescinded two Biden-era memoranda that required federal agencies to obtain software security attestations from software producers before deploying their products. The move withdraws OMB Memoranda M-22-18 and its companion policy M-23-16, which required federal agencies to take a range of actions to align with National Institute of Standards and Technology guidance on software security under former President Joe Biden’s cybersecurity executive order.
OMB Director Russell Vought said the policies imposed unproven and burdensome software accounting processes that prioritized compliance over genuine security investments. In rescinding the mandates, OMB emphasized that agencies may continue to use those tools – but will no longer be required to do so.
The announcement proved a bit polarizing amongst industry stakeholders. We share some of those comments here:
Tim Mackey, Head of Software Supply Chain Risk Strategy, Black Duck
"In rescinding OMB memo M-22-18, OMB memo M-26-05 effectively also rescinded the software assurance elements described in EO 14028. Only the Zero Trust and SBOM topics remain as important elements of EO 14028. While Zero Trust architectures are an important foundation for the modern IT landscape including software factories, and SBOMs provide transparency of 3rd party libraries, neither is an effective risk mitigation model in isolation.
"Notably, M-26-05 first asserts that adherence to the SSDF – a key set of cybersecurity controls expressly designed to produce improved cybersecurity outcomes and described as part of the attestations in M-22-18 – represents 'unproven and burdensome' practices, and then provides a link to the SSDF for options on how to best proceed.
"While it’s debatable whether self-attestations, such as those in M-22-18, are worth much, the reality is that attestation to elements of the SSDF has been a requirement for several years and any associated burden reflects the need to improve cybersecurity practices."
Kevin E. Greene, Chief Cybersecurity Technologist, at BeyondTrust:
"M-22-18 is a knee-jerk reaction to place a liability target squarely on software producers without first establishing proven, repeatable practices that are known to produce better quality and security in software. In the long run, this does more harm than good; it turns software security into an arbitrary, moving target for suppliers.
"Not all practices and processes are created equally. As an industry, we must acknowledge that vulnerabilities in software are inevitable because of the size and complexity in modern software development – which contribute more toward the accumulation of vulnerabilities than a failure to follow a self-attestation process.
"The Trump Administration described self-attestations under M-22-18 as 'unproven and burdensome.' I would go further: enforcing software quality and security through self-attestation fails to shape the behavior of software producers because it prioritizes administrative processes over technical outcomes, inevitably becoming a check-box exercise. It is not a pathway toward software assurance and software security.
"Industry-regarded best practices have never been proven to produce or mature software assurance or security in software. Software construction and deployment are too complex for a one-size-fits-all mandate. Instead, software security must be tailored through software assurance cases that reflect an agency’s specific risk profile and mission needs.
"Software attestation as a concept is vital, but only if its execution is rooted in proven practices with direct traceability to software maturity.
"Software security fails not because of too much oversight, but because of a lack of verifiable attestation and enforceable liability. These are key levers in reducing the cost to maintain software and shaping the behavior in the software construction process. If we want better software, we must give software suppliers a roadmap with proven practices that produce the intended outcomes and reduce risk to mission capabilities."
David Brumley, Chief AI and Science Officer at Bugcrowd
"We agree with the sentiment that a one-size fits all doesn't work, and that in effect the previous EO's turned into compliance-by-paperwork rather than real security validation.
"Of course, cybersecurity is always critical. What experts recommend is real penetration testing for almost anything that has an attack surface. It's common sense, which is why it's so heavily used in industry. We hope that this new EO frees agencies to better tailor their requirements to real improvements."
Randolph Barr, CISO at Cequence Security
"The most important change is that OMB M-26-05 moves agencies away from a compliance-based, checkbox-driven model toward a risk-based cybersecurity approach. While software attestation is no longer universally required, agencies still retain the ability to require attestations, SBOMs, HBOMs, or other assurance artifacts on a case-by-case contractual basis.
"Agencies are being encouraged to focus on real risk reduction and mission impact, rather than satisfying uniform compliance artifacts.
"The critique that the prior memorandum prioritized compliance over genuine security investment is largely fair. In practice, many organizations optimized for producing documentation instead of strengthening operational security. The OMB Memo puts more focus on results than on paperwork. The letter also fills in a gap by making it apparent that there is a risk with hardware. This makes Hardware Bills of Materials (HBOMs) as critical as Software Bills of Materials (SBOMs).
"The reason DORA is a useful comparison is that it represents the opposite end of the spectrum: a highly prescriptive, regulator-driven framework focused on operational resilience, third-party risk, and supply-chain accountability. While DORA applies specifically to the financial sector in the European Union, its control expectations provide a strong reference model for what a mature security program looks like when rigor and consistency are prioritized.
"Large enterprise organizations that have adopted DORA or have built programs capable of meeting DORA-level requirements are often well positioned to satisfy the expectations of OMB M-26-05. DORA-aligned programs typically already include formal risk management, continuous monitoring, incident response testing, third-party oversight, and well-governed SBOM and HBOM processes. As a result, these organizations have a strong advantage when engaging with U.S. federal agencies that operate under a risk-based assurance model. federal agencies operating under a risk-based assurance model.
"This comparison is not meant to suggest that U.S. agencies should adopt DORA wholesale. Instead, it shows that prescriptive frameworks like DORA can be useful for vendors and big companies that want to go above and beyond the minimum standards.
"In short, OMB M-26-05 offers flexibility, while DORA offers structure. Companies that put money into the latter are frequently better able to deal with the former, making them low-risk partners for U.S. federal agencies and other customers with strict rules."
