Software Supply Chain Security Guidance: Attesting to Conformity with Secure Software Development Practices

NIST has defined the following minimum recommendations for federal agencies as they acquire software or a product containing software. These recommendations are intended to assist federal agencies and software producers in communicating clearly with each other regarding secure software development artifacts, attestation, and conformity.

1. Use the SSDF’s terminology and structure to organize communications about secure software development requirements. This enables all software producers to use the same lexicon when attesting to conformity for federal agencies. Software producers can map their secure development methodology to the SSDF’s secure software development practices or associated informative references.
2. Require attestation to cover secure software development practices performed as part of processes and procedures throughout the software life cycle. With the highly dynamic nature of software today, attesting to how things were and are done on an ongoing basis (processes and procedures) is typically more valuable than attesting to how things were done for a specific software release generated by one instance of those processes. This is especially true for post-release practices such as vulnerability disclosure and response, where processes might not yet have been performed for the latest release.
3. Accept first-party attestation of conformity with SSDF practices unless a risk-based approach determines that second or third-party attestation is required. First-party attestation is recommended for meeting the EO 14028 requirements. This is consistent with the guidance in NIST SP 800-161 Rev. 1 (Second Draft), which states in Section 3.1.2: “There are a variety of acceptable validation and revalidation methods, such as requisite certifications, site visits, third-party assessment, or self-attestation. The type and rigor of the required methods should be commensurate to the criticality of the service or product being acquired and the corresponding assurance requirements.”
4. When requesting artifacts of conformance, request high-level artifacts. The software producer should be able to trace the practices summarized in the high-level artifacts to the corresponding low-level artifacts that are generated by those practices. Asking for low-level artifacts for a particular software release is not recommended for meeting the requirements of EO 14028, but may be needed to meet other agency requirements. Reasons for avoiding low-level artifacts include the following:
   • Low-level artifacts provide a snapshot in time of only a small aspect of secure software development, whereas high-level artifacts can provide a big-picture view of how secure software development is performed.
   • Artifacts should address the needs of the audience receiving them, thus providing the necessary information in a usable format for that audience. Understanding low-level artifacts requires the agency to expend considerable technical resources and expertise in analyzing them and determining how to consider them within the context of the broader secure software development practices.
   • Low-level artifacts often contain intellectual property or other proprietary information, or details that attackers could use for hostile purposes, so accepting low-level artifacts gives the agency additional sensitive information to protect.

These minimum recommendations apply to attestation for all software within the scope of this guidance procured by federal agencies, and they should be part of each agency’s processes. The recommendations are not intended to replace more stringent requirements for secure software development that federal agencies may have.

These minimum practices will not be sufficient in some cases. For example, an agency may need greater visibility into the practices for a particular product so that it can better understand how the product would affect the agency’s cybersecurity risk. As discussed in Section 1.4.2 of SP 800-161 Rev. 1 (Second Draft), agencies requiring greater visibility into practices may increase costs for software producers, and thus may increase product prices. See SP 800-161 Rev. 1 for more information on these considerations.

• Introduction
• Guidance Purpose and Scope
• Terminology
• FAQs