On Friday, January 23, the U.S. Office of Management and Budget (OMB) released Memorandum 26-05 cancelling the requirement that vendors who sell commercial software to the government attest to following a set of secure development practices. The required practices were drawn from the NIST Secure Software Development Framework (SSDF) with the selection of specific requirements traceable to a May 2021 presidential executive order.

At SAFECode, we’ve had our concerns about the OMB attestation requirements, but primarily that they were only a subset of the practices called out in the SSDF. We didn’t find the attestation especially burdensome. Any organization that has a mature software security program will almost certainly meet the requirements of the SSDF and produce artifacts as part of its development process that demonstrate doing so, and attestation only required that vendors state that they were following the selected practices.* It didn’t require the production of a “compliance document” that described the vendor’s process and artifacts.

In addition to being reasonably well-aligned with secure software development, the attestation requirements gave a consistent message to vendors: create your secure development process to align with (this subset of) the SSDF and your attestation is valid for the entire U.S. Government. The attestation requirement also provided a consistent baseline for agencies – the vendors’ customers. They could know that the vendors who attested were implementing best practices for secure development without needing to expend scarce software development expertise on developing their own unique software security requirements. If agencies create their own unique attestation requirements, that is likely to require vendors to spend time and effort on analyzing the vendor requirements and creating bespoke attestation packages. That time and effort would be better spent on building more secure software.

It appears to us that the change in attestation requirements is final, so vendors and agencies will have to adapt to this new regime. We urge agencies to consider relying on the SSDF when they request attestation rather than attempting to create their own software security program requirements from scratch. To cite one positive example of US Government adoption, we’ve been happy to see the SSDF adopted in the “DoD Enterprise DevSecOps Activities and Tools Guidebook.”

*We recently collaborated with the Center for Internet Security (CIS) in the creation of a guide to implementing “security by design” by applying the SSDF that includes a spreadsheet that identifies the artifacts that a typical secure development process will create.