Whitepaper · DevSecOps
DevSecOps & CI/CD Security Checklist
Security checks mapped directly onto your pipeline stages (commit, build, test, package, deploy), so each one lands with the team that owns it.
- Category:
- DevSecOps / CI-CD
- Read time:
- 10 minutes
- Applies to:
- GitHub Actions, GitLab CI, Jenkins, Azure DevOps
Most "DevSecOps" checklists read like a tool shopping list: add a SAST scanner here, a container scanner there. The harder problem is that a pipeline has multiple owners (developers, platform/DevOps, security), and a check that lands on the wrong stage either gets ignored or becomes a bottleneck everyone routes around.
So instead of grouping by tool category, this checklist is organized by pipeline stage, the same order code actually travels through on its way to production. Each stage lists what to check and who typically owns fixing it.
Checks by Pipeline Stage
1. Commit
Owner: developers, enforced via pre-commit hooks
- ✓
Secret-scanning runs pre-commit and again in CI, catching keys, tokens and credentials before they're pushed.
- ✓
Commits are signed, and branch protection prevents force-pushes to main/release branches.
2. Build
Owner: platform/DevOps team
- ✓
SAST (static analysis) runs on every pull request, with results visible to the developer before merge, not just logged centrally.
- ✓
Build runners use short-lived, least-privilege credentials (OIDC federation) rather than long-lived static cloud keys.
3. Test
Owner: developers + security
- ✓
Dependency/SCA scanning runs against every build, with a defined policy for what severity blocks a merge vs. just files a ticket.
- ✓
DAST or authenticated security smoke tests run against a staging deploy before production release, for internet-facing services.
4. Package
Owner: platform/DevOps team
- ✓
Container images are scanned for known CVEs, and built from minimal/distroless base images where practical.
- ✓
Build artifacts are signed, and the pipeline verifies signatures before deployment (supply-chain integrity).
5. Deploy
Owner: platform/DevOps team + security review
- ✓
Infrastructure-as-code changes go through the same review and scanning as application code (IaC scanning for misconfigurations).
- ✓
Production deploy credentials require approval from a second person, so no single pipeline run can push to production unreviewed.
- ✓
Rollback is tested and fast, since a security fix that needs to ship urgently shouldn't be blocked by deployment friction.
A Secured Pipeline, End to End
The diagram below shows where each control from the checklist sits in a typical pipeline, from a developer's commit through to a production deployment.
What We Usually Find
During cloud and infrastructure assessments, pipeline-related findings are some of the most consequential because they affect every deployment, not just one application. The most common: long-lived cloud credentials stored as CI secrets (rather than short-lived OIDC tokens), SAST/SCA tools that are configured but whose findings nobody triages, and Infrastructure-as-Code repositories with broader permissions than the workloads they deploy actually need.
The fix is rarely "buy another scanner." It's almost always about closing the loop: making sure findings reach the person who can act on them, at the stage where fixing them is cheapest.
Frequently Asked Questions
Where should we start if we have none of this in place?
Stage 1 (Commit): secret scanning is low-friction, catches one of the most common and damaging issue types, and doesn't require buy-in from multiple teams to implement.
Can you assess our existing pipeline rather than just our application?
Yes, a CI/CD and cloud configuration review is a common engagement for us, looking at pipeline permissions, secret management, IaC configuration and deployment controls against this checklist.
Does this apply if we're not using containers/Kubernetes?
Yes. The stage-based structure applies to any pipeline; the "Package" stage just looks different (e.g. signed deployment artifacts/zip files rather than container images).
How does this relate to a cloud security assessment?
They're complementary: a cloud security assessment (see our Cloud Security Assessment Checklist) looks at the environment your pipeline deploys into; this checklist looks at the pipeline itself.
About the Author
Aditya Thakur
DevSecOps Engineer, CipherTrivia · AWS Certified Security & CKA
Aditya works on CI/CD and cloud infrastructure assessments at CipherTrivia, helping engineering teams integrate security checks into their existing pipelines without adding friction developers route around.
Get a second set of eyes on your pipeline
A CI/CD and cloud configuration review maps your pipeline against this checklist. See our DevSecOps services.
Schedule a Meet