NIST SP 800-218 (SSDF 1.1) asks teams to review or analyze human readable code (practice PW.7) and to test executable code (PW.8), find vulnerabilities before release, and record and triage what turns up. It lets each organization choose methods, so it does not mandate a specific tool.
The source
SSDF version 1.1 was published in February 2022. NIST describes it as a set of high level practices that organizations can fold into the software development life cycle they already use. The practices below come from the framework text.
PW.7: review and analyze code
PW.7.1 asks you to determine whether code review (a person looks at the code) and/or code analysis (tools find issues, alone or with a person) should be used, as defined by the organization. PW.7.2 asks you to perform the review or analysis based on your secure coding standards, and to record and triage all discovered issues and recommended remediations in the team's workflow or issue tracker.
PW.8: test executable code
PW.8.1 asks you to decide whether executable code testing is needed to find vulnerabilities not found by earlier reviews, analysis or testing, and which types to use. PW.8.2 asks you to scope the tests, design them, run them and document results, again recording and triaging every issue.
The notional examples include integrating dynamic vulnerability testing into the automated test suite, using fuzz testing for input handling, adding tests for previously reported vulnerabilities so errors do not return, and using penetration testing in high risk scenarios if resources allow.
Mapping practice to evidence
| Task | Activity | Evidence to keep |
|---|---|---|
| PW.7.1 | Written rule for when review and analysis happen | Policy or engineering standard |
| PW.7.2 | Static analysis and peer review | Scan reports, review records, tickets |
| PW.8.1 | Decision on which tests apply | Test plan or risk note |
| PW.8.2 | Dynamic tests, fuzzing, pen tests | Reports, retest results, tickets |
Steps to get ready
- Write one page stating when code is reviewed and when it is tested, by risk tier.
- Make sure each scanner posts findings to a tracker with an owner and a status.
- Keep reports with dates. Auditors and buyers ask for dated proof.
- Add a regression test whenever a vulnerability is fixed.
Common mistakes
Teams often keep strong practices but weak records. A scan that ran and was ignored looks the same, on paper, as a scan that never ran. Make sure each task above produces something dated: a policy page, a report, a ticket with a status. Also remember that SSDF is a framework of practices, and that customers may ask for more than one source of evidence. Treat the table as a starting map and confirm what your specific buyers expect.
Try it yourself
Click through it at your own pace, or open it full screen.
See how one activity can be mapped to several framework requirements.
Quick check
Does SSDF require a particular scanner?
No. It asks for outcomes and records, and leaves methods to the organization.
Is following SSDF the same as an attestation?
No. Attestation is a separate step with its own rules. Check the requirements that apply to your customers.
Where Safeguard fits
Safeguard provides compliance and evidence automation, SBOM and dependency scanning and policy gates. Try the free scan.
Sources
Last reviewed: 19 October 2026.
