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.
4
artefacts
1
held by a system
1
at each review
moderate
to go live
Source control / CI pipeline
where the evidence lives
teal = a system already holds it · olive = produced at each review
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
Start with the 1 of 4 artefacts that already live in a system (Source control / CI pipeline); keep the periodic reviews but log each one as a dated record with a named reviewer.
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