The White House’s Cybersecurity Executive Order for National Cybersecurity, issued in May 2021, was expected to have a transformative effect on software development practices. While the order primarily applied to those doing business with the US federal government, it was anticipated that industries would also adopt standardized security practices across their software development life cycle, beyond just government-related projects.
One of the key guidelines in the executive order was the requirement for suppliers of software and software-driven products to certify their compliance. This involved meeting specific requirements for software composition analysis (SCA), securing the software chain, and providing software bills of materials (SBOMs). Developers were encouraged to provide SBOMs for all products and track the origins of both internal and third-party software components.
For a while, the industry assumed that SBOMs would be the central defense against software vulnerabilities and supply chain attacks, which were the main concerns prompting the government’s actions. However, as the Cybersecurity and Infrastructure Security Agency (CISA) began to enforce the order, they recently released a Secure Software Development Attestation Form (SSDF) for suppliers to the federal government to self-report their compliance. This caused some confusion, with some mistakenly believing that SBOMs were being downplayed since they were not explicitly required in the form.
In reality, CISA’s guidance heavily relies on the National Institute of Standards and Technology (NIST), particularly its Secure Software Development Framework (SSDF). The SSDF outlines fundamental best practices for developing software in accordance with the executive order’s requirements. While the framework is effective for future products, retrofitting legacy software or modifying products already in development to fully comply with NIST’s guidance is not an easy task.
To address this challenge, NIST attempted to map the executive order’s requirements to the SSDF guidance, emphasizing the need to establish secure software development environments. This includes providing an SBOM for each product and maintaining a trusted source of code supply chain.
Although some may interpret this approach as downplaying the role of SBOMs, they remain a crucial element in meeting federal requirements. SBOMs document the software components involved in development, list dependencies, and identify any known vulnerabilities. CISA affirms this importance by stating that SBOMs can be utilized by software producers to demonstrate compliance with certain minimum requirements.
Furthermore, concerns about public disclosure and intellectual property are addressed by the self-attestation requirement. CISA’s instructions specify that SBOMs need only be available for review and not published, eliminating fears of security exposure or revealing proprietary information. Therefore, the form does not diminish the need for SBOMs.
Additionally, the form provides clarity on the use of tools and artifacts to enhance software supply chain security. It emphasizes the need for a “good-faith effort to maintain trusted source code supply chains” through automation and taking reasonable steps to address the security of third-party components and manage associated vulnerabilities. The form also acknowledges the role of automation in detecting and remediating vulnerabilities, expanding its scope beyond third-party code to encompass security vulnerabilities during development. This supports the use of not only SCA but also tools like static application security testing (SAST) and dynamic application security testing (DAST).
In summary, despite initial confusion, the CISA Self Attestation Form does not undermine the importance of SBOMs as the primary artifact for documenting compliance with the White House’s cybersecurity mandate. On the contrary, SBOMs remain critical to compliance, as clarified by the instructions and subsequent comments. Failure to adopt these new standards and enhance software supply chain security poses significant risks of noncompliance. Therefore, SBOMs are here to stay for the foreseeable future.