White house Rolls Back Federal Software Security mandates, Citing Bureaucratic Burden
Table of Contents
Teh White House has substantially altered the landscape of federal software security, rescinding mandates requiring specific compliance practices due to concerns over administrative overhead. The Office of Management and Budget (OMB) issued Memorandum M-26-05, officially revoking the 2022 policy M-22-18 and its 2023 companion, M-23-16, a move that shifts duty for security posture to individual agencies.
The previous directives centered on stringent secure software progress practices,notably the widespread creation and upkeep of Software Bills of Materials (SBOMs).According to the new memorandum from OMB Director Russell T.Vought,M-22-18 “imposed unproven and burdensome software accounting processes that prioritised compliance over genuine security investments.” This reversal represents a significant departure from centralized control, aiming for a more flexible, risk-based approach.
A Shift in Focus: From Compliance to Risk Mitigation
The rescission effectively rolls back elements of Executive Order 14028 related to software assurance, according to one industry expert. While Zero Trust architectures and SBOMs remain crucial components of the original executive order, they are now viewed as foundational openness tools rather than extensive risk mitigation strategies. “Neither is an effective risk mitigation model on its own,” the expert stated.
Agencies can still require sboms through contractual agreements. The new guidance allows for a Software Development Attestation Form, and can still require SBOMs through contractual agreements.
However, the rationale behind the change has drawn criticism. One analyst pointed out a perceived contradiction within the new guidance: M-26-05 dismisses the Secure Software Development Framework (SSDF) as “unproven and burdensome,” yet concurrently references it as a resource for agencies. “While it’s debatable weather self-attestations…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,” the analyst explained.
For platform engineers, this creates a strategic decision point. While the federal mandate has dissolved, the value of supply chain visibility for internal security governance remains. The US government and its allies continue to advocate for SBOM adoption, suggesting its benefits extend beyond mere compliance. Teams that have already automated SBOM creation may find it efficient to maintain these artifacts for debugging, license compliance, and vulnerability management.
Expanding Scope to Include Hardware Security
A notable expansion within M-26-05 is the explicit inclusion of hardware security. The OMB noted that the previous policy failed to adequately address threats originating from insecure hardware. The new guidance directs agencies to develop assurance policies encompassing both software and hardware components.
This broadened scope brings physical infrastructure into the realm of supply chain risk management. The memorandum directs agencies toward the Hardware Bill of Materials (HBOM) Framework for Supply Chain Risk Management, published by CISA in 2023, to aid in validating the provenance of physical components. Architects designing on-premise or hybrid systems must now consider hardware provenance alongside their software stack.
Regarding cloud platforms, the guidance suggests that contracts requiring sboms should specify the “runtime production environment,” acknowledging the divergence between static code analysis and the dynamic state of live cloud deployments.
The immediate effect of M-26-05 is the removal of the rigid “software accounting” processes deemed distracting by the OMB. However, the basic requirement for security diligence persists.Agencies are still obligated to maintain a comprehensive inventory of both software and hardware.
Platform leads should anticipate a fragmented set of requirements as different agencies develop policies aligned with their specific risk assessments and mission needs.This variability will necessitate flexible release pipelines capable of generating compliance artifacts on demand, rather than as a default setting.The memorandum’s continued reference to the Secure Software Development Framework indicates that,despite the change in enforcement,the underlying technical standards for secure development remain relevant.
The rescission of M-22-18 signals a shift away from centralized software security compliance mandates toward a risk-based, decentralized decision-making process. For software and hardware producers, this likely reduces the administrative burden of universal reporting but introduces the complexity of managing diverse customer requirements.
