What Will CISA’s Secure Software Development Attestation Form Mean? – Source: www.darkreading.com

When the White House issued the Cybersecurity Executive Order for National Cybersecurity in May 2021, observers noted this would transform many software development practices. The order, while it applied to anyone doing business with the US federal government, was expected to lead industries to standardize security practices across their software development life cycle, and not just when dealing with the feds.

One of the order’s central guidelines was a requirement that suppliers of software and software-driven products certify they are in compliance with the executive order, which set down requirements for software composition analysis (SCA), securing the software chain, and software bills of materials (SBOMs). It suggests developers provide SBOMs for all products and track the provenance of internal and third-party software components.

Until recently, the industry has worked on the assumption that SBOMs are the best keystone for a defense against software vulnerabilities and supply chain attacks, two concerns that lit the fire under the government’s feet. But as it works to enforce the order (and a subsequent memorandum), the Cybersecurity and Infrastructure Security Agency (CISA) recently released for comment a Secure Software Development Attestation Form (SSDF) that suppliers to the federal government must use to self-report their compliance. (You may browse comments here.)

This has caused some confusion. CISA’s move has given some the wrong idea that SBOMs are being de-emphasized because they are not a required artifact needed to comply. But the form only formalizes the role of the SBOM as the first line of defense.

CISA’s guidance relies strongly on the National Institute of Standards and Technology, especially its Secure Software Development Framework (SSDF), which set down some fundamental best practices. This is quickly becoming the template to build software in compliance with the requirements of the executive order. This framework is all well and good for products being developed in the future, but it is not so easy to retrofit legacy software or alter products already in the development pipeline to conform to the NIST guidance in full. retroactively.

NIST tried to address this by mapping the order’s requirements (PDF) to the SSDF guidance, especially centering compliance on the need to institute secure software development environments. For example, it requires providing an SBOM for each product and maintaining a trusted source of code supply chain.

CISA’s Self-Attestation Form Elevates SBOMs

On the surface, this approach may appear to minimize the role of SBOMs, but in fact they are still an important element for satisfying federal requirements, along with application security testing technologies including static application security testing (SAST), dynamic application security testing (DAST), and more. CISA only proposes that the federal government’s suppliers state they follow specific aspects of the SSDF, including using SBOMs, to confirm their vulnerability detection and remediation handling.

Skipping the use of SBOMs to document third-party software inventory and vulnerability exposure would be a risky move. SBOMs are key to detailing the software components involved in software development and itemizing dependencies, as well as any known vulnerabilities. As CISA stated: “Establishing and maintaining processes for producing and maintaining a current SBOM may be utilized by the software producer as a means of documenting compliance with certain minimum requirements.”

Additionally, the self-attestation requirement dials back concerns over public disclosure among suppliers, who worry about security exposure or revealing intellectual property. CISA’s instructions suggest the SBOMs must only be available for review, not published, so it does not reduce the need for them.

The form also clarifies the use of tools and artifacts to improve software supply chain security. It requires “a good-faith effort to maintain trusted source code supply chains” using automation and “reasonable steps to address the security of third-party components and manage related vulnerabilities.” It also goes further in explaining the place of automation in detection and remediation of vulnerabilities, extending their scope beyond third-party code to security vulnerabilities during development, which supports the use of not just SCA but also SAST, DAST, and other tools.

Getting Past First Impressions

Despite first impressions, the CISA Self Attestation Form doesn’t undermine SBOMs as the main artifact for software developers to document compliance with the White House’s cybersecurity mandate. On the contrary, they are still a critical artifact in compliance, as the instructions — and resulting comments — demonstrate. The instructions now spell out clearly the role of software composition analysis and SBOMs going forward.

SBOMs aren’t going away any time soon. Any delays in enacting these new standards and improving software supply chain security only adds to the risks from noncompliance.