Securing CI/CD Pipelines: Common Vulnerabilities and How to Fix Them
Your deployment pipeline has access to everything: source code, secrets, and production. That makes it one of the highest-value targets in your organization, and one of the most overlooked. A compromised pipeline does not just leak data; it lets an attacker ship their code as yours. Here are the weak points we see most, and how to close them.
Secrets in the pipeline
The most common finding is secrets where they should not be: hardcoded in a repo, printed in build logs, or sitting in plaintext environment variables. The first check is your own history, secrets committed months ago are still valid until rotated.
bash
# Scan a repo's full history for committed secrets
pip install detect-secrets
detect-secrets scan --all-files
# Or with gitleaks
gitleaks detect --source . --report-format sarif --report-path leaks.sarifMove secrets into a proper store (a vault or your platform's secret manager), inject them at runtime, mask them in logs, and rotate anything that was ever exposed.
Dependency and supply-chain risk
Pipelines pull in hundreds of dependencies, any of which can carry a known vulnerability or, worse, be a typosquat or a confused-dependency pull from the wrong registry. Pin versions, verify integrity, and scan on every build:
bash
# Audit dependencies for known vulnerabilities in CI
npm audit --audit-level=high # Node
pip-audit # Python
# Fail the build on high/critical findings rather than just warningLeast privilege for the runner. The biggest force multiplier is limiting what the pipeline itself can do. Short-lived, narrowly scoped credentials, isolated runners, and minimal egress mean that even a compromised build job cannot reach production or exfiltrate to an attacker.
Protect the path to production
Beyond secrets and dependencies, lock down the workflow: require reviews on pipeline configuration itself (a malicious change to a build file is a code change), sign and verify build artifacts, and keep an audit log of who deployed what. Branch protection that developers can bypass is not protection.
Test it like an attacker would
These controls look fine on paper and fail in practice more often than teams expect, an overlooked token here, an over-permissive runner there. A penetration test that includes your build and deployment path finds those gaps before someone else does. It fits alongside cloud security testing, since pipelines and cloud identities are deeply intertwined.
Want your CI/CD and cloud path reviewed by senior testers? Get in touch and we will scope it with you.
