CI/CD security is the practice of protecting the systems that turn source code into deployable software. It covers who can change a pipeline, what code and dependencies enter a build, which credentials the build can use, what security checks must pass, and whether those controls remain active over time.
It is broader than adding a scanner task. A secure pipeline combines identity, least privilege, protected branches, repeatable scanning, authoritative policy, and continuous verification of the pipeline configuration itself.
The five layers of CI/CD security
- Source control: protect critical branches, require pull requests, and review sensitive paths.
- Build identity: limit job-token scope and avoid credentials shared across unrelated pipelines.
- Dependencies and code: run SCA, SAST, secrets, container, and IaC checks where relevant.
- Enforcement: translate findings into a consistent pass, monitor, or fail decision.
- Operations: inventory coverage, detect configuration drift, and retain an audit trail.
Why one-time hardening is not enough
Pipelines change constantly. Templates are refactored, service connections are renamed, new repositories appear, and temporary exceptions linger. CI/CD security therefore needs a desired state and a reconciliation loop—not a checklist completed once during onboarding.
How to measure the program
Finding totals are not coverage metrics. Start with the percentage of eligible pipelines enrolled, the percentage enforcing policy, the number currently drifted, synchronization freshness, and the age and ownership of exceptions. Those numbers describe whether the security system is actually operating.
