PO.4.1 Criteria for Software Security
Define criteria for assessing the security characteristics of software before release. Tie criteria to risk and to customer commitments so that release decisions are explicit.
Source: NIST SP 800-218 (SSDF), PO.4.1. The statement above is our statement of the clause, read from the published text and cited so you can check it against the official text, not the instrument verbatim. Open NIST SP 800-218 (SSDF) in the compliance library.
These are the artefacts auditors commonly ask for on this requirement, our guidance rather than text from the standard. Your assessor decides what is sufficient in your context, and asks for samples across the period when a report covers one.
system holds itEvidence a system already holds
- Metrics on releases with open critical findings · Source control / CI pipeline
periodic reviewEvidence produced at each review
- Release readiness review records · Source control / CI pipeline
governing documentDocuments that govern the control
- Release security criteria document · Policy repository / GRC workspace
- Risk acceptance workflow · Policy repository / GRC workspace
First move
Common gaps auditors find
- release criteria exist but releases ship regardless of criteria
- no risk acceptance workflow tied to release
- criteria not differentiated by product risk tier
Do this for your whole sheet
Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.
Build my evidence sheetPO.3.3 Toolchain Generates Security Artifacts · PO.4.2 Gather and Safeguard Security Check Information