Compliance FrameworksAmericas
NIST SSDF
NIST Secure Software Development Framework: supply chain integrity, provenance, and vulnerability management.
NIST Secure Software Development Framework: supply chain integrity, provenance, and vulnerability management.
| Region | Americas |
| Country or scope | United States |
| Sector | Government |
| In your workspace | On unless you switch it off in Compliance › Manage. |
How Safeguard covers NIST SSDF
- Scan requirements: 6, all decided by a scan.
- Controls: the scan requirements below, plus 14 controls from Safeguard's control catalog for NIST SSDF.
- Automated tests: none map to it directly. You can link any automated test to its controls yourself (how).
- Policy templates: 26: 4 written for NIST SSDF and 22 from the standard set.
How each kind of coverage works, and what the readiness score counts: Compliance frameworks.
What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
|---|---|---|
SSDF-PS-3-2 Provenance Data / SBOM | Producers should collect, safeguard, and share provenance data for all software release components, such as an SBOM identifying the creating tool or organization (SP 800-218 PS.3.2) | Scan |
SSDF-PS-2-1 Release Integrity Verification | Acquirers must be able to verify software release integrity, which requires publishing cryptographic hashes for released components (SP 800-218 PS.2.1) | Scan |
SSDF-PW-4-1 Acquire Well-Secured Components | Reused third-party components must be acquired from known, evaluated sources, requiring the supplier of each component to be identified (SP 800-218 PW.4.1) | Scan |
SSDF-PW-4-4 Verify Acquired Components | Acquired components must be verified against their expected identity before reuse, requiring precise component identifiers such as PURLs (SP 800-218 PW.4.4) | Scan |
SSDF-RV-1-1 Identify Vulnerabilities in Components | Producers must gather information on potential vulnerabilities in the software and its third-party components, which requires every component to carry an exact version for advisory matching (SP 800-218 RV.1.1) | Scan |
SSDF-PW-4-2 Complete Component Records | Well-secured reuse of software requires maintaining complete records of components in use, with both name and version documented for each (SP 800-218 PW.4 practice group) | Scan |
More controls in the catalog
The framework's Controls tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
|---|---|
PO.1.1 | Define security requirements for software development |
PO.2.1 | Implement a secure development environment |
PO.3.1 | Provide security training for developers |
PO.5.1 | Implement supply chain risk management for development tools |
PS.1.1 | Design software to meet security requirements |
PS.2.1 | Review and test software for security vulnerabilities |
PS.3.1 | Archive and protect software release artifacts |
PW.1.1 | Use secure coding standards |
PW.4.1 | Reuse existing well-secured software components |
PW.5.1 | Create source code securely |
PW.7.1 | Perform security testing throughout development |
RV.1.1 | Identify and confirm vulnerabilities in released software |
RV.2.1 | Analyze vulnerabilities to determine root causes |
RV.3.1 | Address vulnerabilities and notify affected parties |
Policy templates
Written for NIST SSDF:
- Organization-Wide Software Security Requirements
- Software Integrity and Supply Chain Protection Policy
- Secure Software Development Practices Policy
- Vulnerability Response and Disclosure Policy
And 22 from the standard set, adapted to NIST SSDF.