Security Hardening of DevOps Pipelines
A CI/CD pipeline has broad access almost by design — it touches source code, credentials, and production. That makes it a serious target if it isn't hardened deliberately, not an afterthought once everything else is working.
1. Attack Surface Assessment
We map what the pipeline can actually reach — which credentials, which environments, which approvals are required — and who can trigger a run, before deciding what to lock down.
- Trigger surface: what can start a pipeline run — a push, a PR from a fork, a manual trigger — and whether external contributors can trigger privileged jobs.
- Credential inventory: every credential the pipeline can access, and whether each one is actually still needed.
- Third-party action review: pipeline steps that pull in third-party actions or plugins, which are themselves a supply chain risk if unpinned or unreviewed.
- Blast radius mapping: what a fully compromised pipeline run could actually do, end to end.
2. Secrets Management
Credentials move out of pipeline configuration files and repository history into a proper secrets manager, injected only at runtime and only where needed.
- Dedicated secrets store: Vault, AWS Secrets Manager, or the platform's built-in secrets — never plaintext in a YAML file or repo history.
- Scoped injection: a secret is available only to the specific job that needs it, not the entire pipeline by default.
- Rotation policy: credentials rotated on a schedule and immediately after any suspected exposure, not left unchanged indefinitely.
- History scrubbing: any secret found already committed to history gets rotated and the exposure treated as real, since git history doesn't forget.
3. Dependency and Image Scanning
Every build is scanned for known vulnerabilities in dependencies and container images before it ships, catching issues at the cheapest point to fix them.
- Software composition analysis (SCA): open-source dependencies checked against known vulnerability databases on every build.
- Container image scanning: base images and installed packages scanned for CVEs before an image is allowed to deploy.
- Static analysis (SAST): code scanned for common vulnerability patterns as part of the pipeline, not only during occasional manual review.
- Build-breaking thresholds: critical findings block the build; lower-severity ones are tracked without halting every release over a minor issue.
4. Least-Privilege Permissions
Pipeline service accounts and tokens are scoped to exactly what each job needs — a deploy job doesn't need the same access as a linting job.
- Per-job scoping: a linting job gets read-only repo access; a deploy job gets deploy access — not one broad token used everywhere.
- Short-lived credentials: tokens that expire quickly or are generated per-run, instead of long-lived static credentials sitting in configuration.
- Environment-specific access: production deploy credentials isolated from staging and dev, so a staging compromise doesn't reach production.
- Regular permission audits: pipeline permissions reviewed periodically, since scope tends to expand over time unless someone actively checks.
5. Supply Chain Integrity
Builds are signed and paired with a software bill of materials (SBOM), so you can prove exactly what shipped and that it wasn't tampered with along the way.
- Artifact signing: builds cryptographically signed so tampering after the build step is detectable.
- SBOM generation: a software bill of materials produced for every release, listing exactly what's inside it.
- Provenance tracking: a verifiable record of which pipeline run, commit, and inputs produced a given artifact.
- Verification at deploy time: signatures and provenance checked before deployment, not just generated and forgotten.
Contact us for a pipeline security review, or to harden a CI/CD setup that's grown organically without much thought to security.