CISA has provided a clearer understanding of what is needed for compliance with the White House Cybersecurity Executive Order (EO 14028). They are currently circulating for comment their instructions for the “Secure Software Development Attestation Form.”
In the past, it was assumed that the software bill of materials (SBOM) would be the main artefact needed to comply with the EO, as it does appear many times in the document. The industry has since been busy working out how to use the SBOMs to achieve the goals of the EO. With the release of the new attestation form, SBOMs may no longer be the only artefact needed for compliance. Self-attestation requires organization claim compliance with EO, which has specific requirements for software composition analysis (SCA), securing the software chain, and SBOMs, which still play an important role.
NIST Provides the Fundamental Guidance and Standards
The self-attestation form emphasizes that the guidance for secure software development comes from NIST and, in particular, the “Secure Software Development Framework” (SSDF, NIST SP 800-218). In the future, this should be the guiding document on how to build EO 14028-compliant software.
For existing products and projects in flight, however, it’s difficult to conform to this NIST guidance in full, retroactively. For this reason, NIST has mapped the requirements of EO 14028 to the guidance in the SSDF. In particular, compliance centers around the need to establish secure software development environments. Examples of these requirements include:
- checking software for vulnerabilities and remediating them
- Provide an SBOM for each product
- Maintain a trusted source of code supply chains, etc.
Fundamentally, what CISA is proposing now is that suppliers to the federal government must self-attest that they have followed particular aspects of the SSDF, defined by the form, which include the use of SBOMs, SCA tools, and, more than likely, other tools such as SAST tools to ensure coverage of vulnerability detection and remediation.
The Role of SBOMs in Self Attestation
Although the role of the SBOM might seem reduced in the new self-attestation approach, this is really not the case. In fact, SBOMs remain essential for compliance, as there really is no alternative to ensuring compliance with the NIST SSDF. SBOMs are essential for documenting software composition and itemizing dependencies (and known vulnerabilities for each) in software.
Here is specifically what the CISA self-attestation form instructions say about SBOMs:
“Software producers may be asked by agencies to provide additional attestation artifacts or documentation, such as a Software Bill of Materials (SBOMs) or documentation from a third-party assessor, beyond what is required by this common form. 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.”
Clearly, it would be risky for software companies to avoid using SBOMs to document their third-party software inventory and vulnerability exposure. The use of SCA tools and the generation of SBOMs as part of a secure development process are still very much required.
Self-attestation may also reduce suppliers’ fear of public disclosure of SBOMs. Many organizations claimed this would be a security problem or expose their intellectual property. The new guidance implies that public disclosure isn’t required, but SBOMs must be available for assessment, clearly not diminishing the need for SBOMs.
Specific Requirements for Tools and Artifacts Related to SBOMs in Self-Attestation
The self-attestation form is clear in several parts about the use of tools and artifacts to improve software supply chain security. For example, Part 2 of the form includes:
“2) The software producer has made a good-faith effort to maintain trusted source code supply chains by:
b) Employing automated tools or comparable processes; and
c) Establishing a process that includes reasonable steps to address the security of third-part components and manage related vulnerabilities; “
These requirements imply that, in practice, automation tools are needed to analyze software brought in via the supply chain, document the results, and mitigate risks. The form goes further with specifics on automation and detecting, managing, and mitigating security vulnerabilities:
“4) The software producer employed automated tools or comparable processes that check for security vulnerabilities. In addition:
a) The software producer ensured these processes operate on an ongoing basis and, at a minimum, prior to product, version, or update releases and
b) The software producer has a policy or process to address discovered security vulnerabilities prior to product release; and
c) The software producer operates a vulnerability disclosure program and accepts, reviews, and addresses disclosed software vulnerabilities in a timely fashion. “
These requirements increase the scope of vulnerability detection beyond third-party code and include the detection and management of security vulnerabilities during development. This makes a strong case for not just SCA tools but also application security testing tools like SAST, DAST, and others.
Summary
Despite the impression that the CISA Self Attestation Form takes away the focus on SBOMs as the primary artifact for compliance with the White House Cybersecurity Executive Order, they are still critical artifacts in compliance.
In fact, the instructions for self-attestation now make clear the role of software composition analysis and SBOMs. SBOMs aren’t going anywhere, and delaying software supply chain security for government software suppliers risks significant impact from non-compliance.
