DevSecOps
DevSecOps Security Review: Securing CI/CD, Secrets, and Build Runners
A practical guide to protecting source control, CI/CD, secrets, build runners, and release approvals.
Why the delivery pipeline is a target. A pipeline can access source code, build runners, signing keys, packages, cloud credentials, and production deployments. A compromise can ship malicious code through an otherwise trusted release process. The review examines the whole path: developer workstation, repository, pull request, build, artifact registry, deployment, and production approval.
Source-control testing reviews MFA, administrator roles, branch protection, mandatory review, tags, repository visibility, and service-account use. The key principle is separation of duties: one account should not quietly change code, approve it, and deploy it to production without meaningful controls.
Build, dependency, and secret testing covers isolated runners, pinned actions, minimal pipeline permissions, artifact provenance, dependency policy, vulnerability scanning, and immutable outputs. Secrets should live in a dedicated manager, be injected only when needed, masked in logs, rotated, and unavailable to untrusted pull requests or forks.
Release controls should define environments, protected production approvals, change visibility, rollback, and verification that the deployed artifact is the reviewed artifact. Feature flags can reduce blast radius, but they need owners and auditability. Security gates should be useful: fast checks on every change, deeper checks for high-risk work, and recorded exceptions.
The roadmap prioritises excessive CI permissions, exposed secrets, unprotected branches, weak artifact integrity, and weak deployment approval. Teams then automate repeatable checks so security supports delivery instead of becoming a last-minute hurdle.
Table of Contents
- Why the pipeline is high value
- Threat model
- Safe secret example
- Risk and root cause
- Secure delivery controls
Why the Delivery Pipeline Is a High-Value Target
A delivery pipeline can read source code, use credentials, build artifacts, and deploy production systems. A compromise here can bypass controls that protect an individual application feature.
Developer → source control → CI build → artifact registry → approval → production
Pipeline Threat Model
Review source-control identities, protected branches, pull-request approvals, build runners, secrets, dependencies, artifact provenance, deployment permissions, and audit visibility.
Treat build definitions and infrastructure code as production code: they deserve review, ownership, and test coverage.
Safe Secret-Exposure Example
A developer accidentally commits a test credential. A secure response includes revoking and rotating it, determining whether it was used, adding preventive scanning, and restricting future secret access to approved workloads.
Removing the text from a repository is not enough if the credential remains usable or has already been copied into logs or artifacts.
Secure Delivery Controls
- Require MFA, protected branches, peer review, and minimal administrator access.
- Use short-lived workload identity and a governed secret manager.
- Isolate build runners and avoid exposing secrets to untrusted contributions.
- Pin and review dependencies; maintain artifact provenance.
- Require environment-appropriate approvals and immutable audit records for production releases.
Risk Rating
| Severity | Description |
|---|---|
| Critical | An unauthorized actor could change production code, artifacts, or deployment control without meaningful safeguards. |
| High | Pipeline secrets, privileged CI identities, or protected branches can be materially abused. |
| Medium | A constrained weakness weakens review, provenance, or release assurance. |
| Low | A limited hardening gap has little direct impact in the current workflow. |
DevSecOps Security Checklist
- Source control requires MFA, protected branches, and review.
- Secrets are in approved vaults and are rotated after exposure.
- Pipeline identities are short-lived and least privileged.
- Dependencies are pinned, reviewed, and monitored.
- Artifacts are traceable to approved builds and deployments.