Well-Architected & DevSecOps Review
CI/CD Pipeline Security Review
The pipeline has production credentials. It deserves the same scrutiny as production.
- Turnaround
- 5–7 business days
- Who it is for
- Teams deploying continuously, especially with self-hosted runners.
01 — The problem
Build systems are the softest route to production in most organisations: they hold deploy credentials, run third-party code on every build, and are rarely covered by the controls applied to the infrastructure they deploy to.
02 — What is included
Exactly what you get, and nothing vague.
- Secret handling across the pipeline, including what lands in build logs
- SAST, DAST and container scanning placed where they will actually block
- OIDC federation to replace long-lived cloud credentials in CI
- Runner isolation and third-party action pinning
- Branch protection and deploy approval paths that cannot be bypassed
03 — What this usually finds
The recurring ones, named up front.
- Long-lived cloud keys in CI secrets where OIDC would work
- Third-party actions pinned to a mutable tag
- Scanners that run but never fail a build
- Self-hosted runners shared between public and private repositories
Listed because they recur, not because they are guaranteed. The audit reports what is actually there.
Next step
Twenty minutes to find out whether this is worth doing.
Every engagement runs under a signed mutual NDA with a read-only IAM role. If the audit would not pay for itself, I will say so on the call.