A CI pipeline can produce evidence for tasks such as dependency checks, tests, build settings, release archives and SBOMs. It cannot produce evidence of judgment: roles, leadership commitment, design review, disclosure policy and root cause analysis need human records. Sort tasks into those two groups before automating.
Why sort first
NIST PO.3 says to use automation to reduce human effort and improve accuracy and reproducibility, and also to document and demonstrate the use of practices. Automation is encouraged, but not every task has a machine-readable output. If you try to automate everything you end up with logs that say little, and gaps where real decisions happen.
The sorting table
| Practice area | Pipeline can show | People must record |
|---|---|---|
| PO.1, PO.2 | Nothing directly | Policies, roles, training, sign-off |
| PO.3, PO.4 | Gate runs, tool config, pass or fail history | Why the criteria were chosen |
| PO.5 | Environment configuration exports | Reviews of access |
| PS.1 to PS.3 | Repo settings, signatures, archived artifacts, SBOMs | Retention decisions |
| PW.1, PW.2 | Little | Threat models, design review findings |
| PW.4 | Dependency scans, component lists | Approval of components |
| PW.5 to PW.6 | Linter and compiler settings in config | Secure coding guidance |
| PW.7, PW.8 | Required reviews, test results | Review judgment, test scoping |
| PW.9 | Config in version control | Baseline reasoning |
| RV.1, RV.2 | Scan alerts, ticket timestamps | Triage decisions, advisories |
| RV.3 | Little | Root cause notes, process changes |
This split is our own working view, based on the kinds of artifacts each task naturally leaves.
Steps
- Mark each task in your index as automatic, manual or mixed.
- For automatic tasks, set the pipeline to store its output in a retained location and name the retention period.
- For manual tasks, create a template so the record is short and consistent.
- For mixed tasks, link the human decision to the automated output, such as a design review ticket linking the build that implemented it.
Watch for false comfort
A green pipeline shows a check ran. It does not show the check is the right one. Review the criteria in PO.4.1 yearly, and keep a record of changes to the pipeline itself. Our post on gate criteria and evidence goes deeper.
Protect the evidence
Pipeline logs can be altered by anyone who controls the pipeline. Limit who can edit retention settings and send logs to a location the build system cannot rewrite. This links to PO.5 on protecting development environments.
Start with the cheap wins
Begin with evidence your pipeline already produces: test results, dependency scan output and build logs. Make sure they are stored for as long as your retention policy says and that each is tied to a release or commit. Then add SBOM generation and signature records. After that, spend time on human templates for the judgment tasks. This order delivers evidence quickly and exposes where the manual work really is.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how a gate records its result on a pull request, which is the kind of artifact CI evidence is made of.
Quick check
Can we automate all of PO?
No. Policies, roles and commitment are human decisions. Automation helps with toolchain and environment evidence.
Is a passing pipeline proof of SSDF alignment?
No. It is one kind of artifact. A reviewer will also want policies, ownership and records of decisions.
Safeguard's policies, gates and guardrails and its compliance and evidence automation cover the automatic side. The free scan is at gold.safeguard.sh/scan.
Sources
- NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1
- NIST CSRC publication page for SP 800-218
Last reviewed: 19 October 2026.
