White House rescinds software security compliance mandates


The White House has rescinded software security compliance mandates due to concerns about administrative overhead.

The Office of Management and Budget (OMB) issued Memorandum M-26-05 (PDF) which officially revokes the 2022 policy known as M-22-18 and its 2023 companion policy, M-23-16. This reversal alters the governance landscape for enterprise architects and platform engineers who service federal contracts or align with federal standards.

The previous directives mandated specific secure software development practices, including the widespread generation and maintenance of Software Bills of Materials (SBOMs). The new memorandum from OMB Director Russell T. Vought argues that M-22-18 “imposed unproven and burdensome software accounting processes that prioritised compliance over genuine security investments.”

Tim Mackey, Head of Software Supply Chain Risk Strategy at Black Duck, notes that in rescinding M-22-18, the new memo effectively rolls back the software assurance elements described in Executive Order 14028.

“Only the zero trust and SBOM topics remain as important elements of EO 14028,” Mackey explains. He warns that while Zero Trust architectures and SBOMs provide foundational transparency, “neither is an effective risk mitigation model in isolation.”

The central premise of the new guidance is a decentralisation of security authority. Responsibility now rests explicitly with individual agency heads to determine the appropriate security posture for their specific environments. The OMB states there is “no universal, one-size-fits-all method” for securing government networks.

For technical leads, this suggests a departure from rigid and almost checklist-based compliance toward a model that prioritises threat modelling and context. Agencies must now validate provider security by using secure development principles and conducting comprehensive risk assessments. This approach allows departments to tailor their assurance requirements rather than adhering to a blanket government-wide standard that may not fit every mission.

Impact on DevSecOps and toolchains

Many engineering teams have spent the last three years integrating SBOM generation and attestation workflows into their CI/CD pipelines to meet the requirements of the now-rescinded M-22-18. The new directive does not ban these practices but changes their status from mandatory to optional.

The memorandum clarifies that agencies “may choose to use the government-wide secure software development resources developed under M-22-18,” specifically mentioning the Secure Software Development Attestation Form. Furthermore, agencies retain the option to adopt contractual terms requiring a software producer to provide a current SBOM upon request.

However, the logic behind the change to software security compliance has drawn scrutiny from industry experts. Mackey points out a contradiction in the new guidance: M-26-05 first dismisses adherence to the Secure Software Development Framework (SSDF) as “unproven and burdensome,” but then links to that very same SSDF as a resource for agencies to use.

“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,” Mackey explains.

For platform engineers, this creates a decision point. While the federal mandate has dissolved, the utility of supply chain visibility remains for internal security governance. The US government and its allies have released guidance highlighting the advantages of SBOM adoption, suggesting the practice retains value beyond compliance.

Teams that have already automated these artifacts may find it efficient to maintain them for debugging, license compliance, and vulnerability management, even if the external pressure has subsided.

Hardware and cloud environments

A notable expansion in M-26-05 is the explicit inclusion of hardware security. The OMB noted that the previous policy “neglected to account for threats posed by insecure hardware.” The new guidance directs agencies to develop assurance policies that cover both software and hardware.

This brings physical infrastructure into the scope of supply chain risk management. The memorandum points agencies toward the catchily-named ‘Hardware Bill of Materials (HBOM) Framework for Supply Chain Risk Management’ published by CISA in 2023. Architects designing on-premise or hybrid systems will need to consider how to validate the provenance of physical components alongside their software stack.

Regarding cloud platforms, the guidance offers specific advice for agencies that choose to maintain SBOM requirements. It suggests that contracts should specify that the producer must provide an SBOM of the “runtime production environment” upon request. This distinction addresses the difference between static code analysis and the actual state of a live cloud deployment, which often drift apart.

Navigating fragmented software security compliance

The immediate effect of M-26-05 is the removal of the rigid “software accounting” processes that the OMB deemed distracting. However, the requirement for security diligence remains. Agencies are still required to maintain a complete inventory of software and hardware.

Platform leads should anticipate a fragmented set of requirements as different agencies develop policies that “match their risk determinations and mission needs.” One agency might continue requiring full attestation and SBOMs, while another might prioritise different validation methods. This variability will require flexible release pipelines that can generate compliance artifacts on demand rather than by default.

The memorandum also references the Secure Software Development Framework as a continued resource for information and options. This indicates that while the enforcement mechanism has changed, the underlying technical standards for secure development remain relevant references for engineering teams.

The rescission of M-22-18 signals a move away from centralised software security compliance mandates toward risk-based decision-making. For software and hardware producers, this likely reduces the administrative burden of universal reporting but increases the complexity of managing customer requirements.

See also: Keeper Security: Software supply chain threats have evolved

Want to learn more about cybersecurity from industry leaders? Check out Cyber Security & Cloud Expo taking place in Amsterdam, California, and London. The comprehensive event is part of TechEx and is co-located with other leading technology events including the AI & Big Data Expo. Click here for more information.

Developer is powered by TechForge Media. Explore other upcoming enterprise technology events and webinars here.