Evidence
Secure development: what evidence looks like in a CI pipeline
Engineering teams tend to do more than they can prove. The audit gap is traceability rather than practice.
Published: Facts checked:
What secure development evidence do auditors want?
That code is reviewed by someone other than its author; that dependency and static analysis run, with a decision recorded where something is found; that secrets are not committed, with a check that enforces it; and that deployment is separated from development, with production access limited.
The pipeline is the evidence. A pull request with a reviewer, a passing scan and a deployment record is a complete trail, and it is produced by the work rather than by anybody assembling it later — which is the definition of a control worth having.
The bottom line
Make the pipeline enforce what the policy claims. Then the evidence is a by-product rather than a project.
Related services
Secure Code Review
A reviewer reading your code for the flaws a scanner cannot see — with the scanner’s output triaged rather than forwarded.
SOC 2 Type 2 Readiness
Evidence that your controls ran for months, not that they existed on a date — the report enterprise procurement usually means.
ISO/IEC 27001 — Information Security Management
Build an information security management system that survives Stage 2 — and the three years of surveillance that follow.
Related insights
Evidence
Running an internal audit that is worth the day it costs
Its job is to find things before the external auditor does, not to pass.
Evidence
Corrective action is not the same as fixing it
A fix addresses the instance. Corrective action addresses why it happened.
Evidence
Evidence that collects itself
If producing evidence is a separate task, it will be skipped in a busy quarter.
