Introduction
Your CI/CD pipeline is the most privileged system in your organization. It has access to source code, secrets, production credentials, cloud provider APIs, and the ability to deploy code that your users will run. A compromised build pipeline is a compromised organization. And yet, in most environments I audit, the pipeline has weaker security controls than the production systems it deploys to.
The Attack Surface
A typical modern pipeline involves: a source code repository (GitHub, GitLab, Bitbucket), a CI server (Jenkins, GitHub Actions, CircleCI, GitLab CI), artifact storage (Docker registries, package repositories, S3 buckets), secrets management (Vault, AWS Secrets Manager, environment variables), and deployment targets (Kubernetes, EC2, Lambda). Each component is a potential compromise point.
The Codecov attack compromised the Bash Uploader script used in thousands of CI pipelines. The SolarWinds attack modified code during the build process. The event-stream npm attack injected malicious code into a dependency. All of these were build pipeline attacks, and all of them succeeded because the pipeline itself was not adequately secured.
Hardening Your Pipeline
Protect your CI/CD server like a production system. Patch it. Restrict network access. Require MFA for all admin access. Monitor its logs. If you are running self-hosted Jenkins, treat it as a tier-1 critical asset — because an attacker who controls Jenkins controls your production environment.
Isolate builds. Every build should run in a fresh, ephemeral environment — a container or VM that is created for the build and destroyed afterward. Build environments that persist between builds accumulate state that can be poisoned. Never run builds on shared, long-lived infrastructure.
Manage secrets properly. Never store secrets in CI configuration, environment variables visible in logs, or source code. Use a dedicated secrets manager with short-lived, scoped credentials. Rotate secrets after any pipeline compromise or team member departure.
Sign and verify artifacts. Sign your build artifacts (container images, packages, binaries) and verify signatures before deployment. Cosign (for containers) and Sigstore (for general-purpose signing) provide free, open-source solutions. This ensures that what you built is what you deploy, with no tampering in between.
SLSA Framework
SLSA (Supply-chain Levels for Software Artifacts) provides a maturity model for build pipeline security, from Level 1 (basic provenance documentation) to Level 4 (hermetic, reproducible builds with two-party review). Most organizations should target SLSA Level 2-3, which requires a hosted build platform with provenance generation. Even Level 1 — documenting what was built, when, from what source, by what process — is a significant improvement over having no build provenance at all.
