Your Pipeline Is Now Part of Your Attack Surface
Modern CI/CD pipelines have direct access to source code, secrets, and production deployment capability — making them a genuinely high-value target that, if compromised, can let an attacker inject malicious code that gets deployed with full legitimacy and trust, rather than needing to breach production defenses directly and separately. Supply chain attacks targeting the pipeline itself, rather than the final application, have become a well-documented, recurring pattern in major real-world breaches.
Dependency Risks: Beyond Known Vulnerabilities
Traditional dependency scanning catches known vulnerabilities in specific package versions, but a more insidious, harder-to-detect risk is genuinely malicious code deliberately introduced into a package — through a compromised maintainer account, a convincingly typosquatted package name, or a maintainer intentionally adding malicious code to an otherwise legitimate, previously trustworthy package. Lockfiles, dependency pinning, and increasingly software bill of materials (SBOM) tracking all help manage this risk, though none of them eliminate it entirely on their own.
Verifying Package Integrity
Checksums and cryptographic signatures let you verify that a downloaded package genuinely matches what the maintainer actually published, rather than a tampered or substituted version injected somewhere along the distribution chain. Package managers increasingly support this verification natively, but it requires actually enabling and enforcing it — the protection isn’t automatic just because the underlying capability technically exists in the tooling.
Securing CI Pipeline Credentials
CI pipelines routinely need credentials to deploy, access cloud resources, and pull private dependencies — and these credentials are a genuinely high-value target if the pipeline itself is compromised through any other vector. Scope pipeline credentials narrowly to exactly what each specific job actually needs, use short-lived, automatically-expiring credentials wherever your tooling supports it, and never expose broad, standing production credentials to pipeline steps that don’t genuinely require that level of access for their specific task.
Pinning Actions and Third-Party CI Steps
CI platforms like GitHub Actions let you reference third-party actions by name and tag, but tags can be moved to point elsewhere by anyone with write access to that action’s repository, meaning what runs today may not be what runs tomorrow even with an unchanged workflow file. Pinning to a specific commit SHA rather than a mutable tag ensures you know with certainty exactly what code is genuinely executing in your pipeline, rather than trusting that a tag hasn’t been silently, maliciously repointed since you last reviewed it.
Isolating Build Environments
Build steps that execute untrusted or third-party code (running tests against a pull request from an external contributor, for example) should run in genuinely isolated environments without access to sensitive secrets or production credentials. A malicious pull request that can execute arbitrary code during CI shouldn’t automatically have a path to your actual deployment credentials just because it happened to trigger within the same overall pipeline infrastructure.
Signing Build Artifacts
Cryptographically signing build artifacts (container images, packages) at the point of build, and verifying those signatures before deployment, ensures what actually gets deployed is genuinely what your pipeline built — not something tampered with or substituted somewhere in between the build step and the actual deployment step. Tools like Sigstore have made this meaningfully more accessible and practical for organizations without a dedicated, specialized security engineering team to build this capability from scratch themselves.
Monitoring Pipeline Behavior
Unusual pipeline behavior — unexpected outbound network connections during a build, unusual resource consumption patterns, or a workflow file modified in a way that meaningfully changes its actual permissions or credential access — deserves the same monitoring attention as unusual production behavior. Pipeline compromise is often genuinely quiet and gradual rather than dramatically obvious, precisely because attackers benefit from remaining undetected for as long as possible to maximize their access window.
Practical Checklist
- Pin third-party CI actions and steps to specific commit SHAs, not mutable tags that can silently change underneath you.
- Scope pipeline credentials narrowly, using short-lived credentials wherever your tooling genuinely supports it.
- Isolate build environments that execute untrusted or external code from sensitive secrets and production credentials.
- Sign build artifacts and verify those signatures before deployment to detect any tampering in between.
- Monitor pipeline behavior for anomalies with the same rigor and attention you’d apply to production monitoring.