SSDF practice PO.4 asks you to define criteria for software security checks, track them through the life cycle, and gather and protect the information that supports them. In plain terms: decide what counts as a pass, let the toolchain record results, and keep approvals, rejections and exceptions.
The two tasks
PO.4 has two tasks in SP 800-218 version 1.1.
- PO.4.1 Define criteria for software security checks and track them throughout the SDLC.
- PO.4.2 Implement processes and mechanisms to gather and safeguard the information that supports the criteria.
The goal is that software meets your expectations because you defined and used criteria while building it.
What criteria can look like
The document's examples include key performance indicators, key risk indicators and vulnerability severity scores, and adding security criteria to an existing check such as the Definition of Done. Criteria worth writing:
| Criterion | Example form |
|---|---|
| Severity | No open critical findings at release |
| Review | Every change reviewed by a second person |
| Test | Security tests pass in the pipeline |
| Components | No known blocked package versions |
| Exceptions | Documented, owned, time limited |
Gather and protect the evidence
PO.4.2 examples say to use the toolchain to collect information automatically, automate decisions that use the criteria and review them periodically, and allow only authorized people to access the data, with no alteration or deletion. That last point matters to auditors: records that anyone can edit are weak records.
Record security check approvals, rejections and exception requests inside the workflow or tracking system, as the PO.4.1 examples suggest.
Steps to start
- Write five criteria, no more.
- Put each into a pipeline check or a review rule.
- Store results where they cannot be quietly changed.
- Log exceptions with a reason and a review date.
- Look at the data each quarter and tighten the criteria.
Try it yourself
Open the demo and watch a pull request pass or fail against a rule. That recorded decision is a PO.4 artifact.
Click through it at your own pace, or open it full screen.
Quick check
Is PO.4 a requirement to block builds?
No. It asks for defined criteria and recorded checks. Whether a failed check blocks, warns or only logs is your decision.
Who can see the collected data?
The examples say only authorized personnel should access it, and nobody should be able to alter or delete it.
Where tooling helps
Safeguard offers policies, gates and guardrails that record pass or fail results on pull requests, plus compliance and evidence automation. Try the free scan at gold.safeguard.sh/scan. Check the current SSDF text for any newer revision.
Sources
Last reviewed: 19 October 2026.
