The Pipeline as Invisible Critical Infrastructure
Most tech organizations understand that production applications need protection. Firewalls, WAF, anomaly monitoring, penetration testing — these topics land on board agendas and security budgets.
The CI/CD pipeline — the system that builds, tests and deploys that application — rarely appears in the same context. It should. The pipeline has access to everything: API keys, cloud tokens, database secrets, certificates and production deployment permissions. It’s critical infrastructure treated like a dev tool.
The analogy is simple: it’s like investing in armored office doors while leaving all safe keys in an unlocked cabinet in the back room. The pipeline is that cabinet.
Where Does This Gap Come From?
The CI/CD pipeline is perceived as an internal developer tool. Unlike public-facing applications, it’s not “visible from the internet” — so intuitively it seems less risky. This assumption is wrong for several reasons.
First, pipelines are accessible through web interfaces (GitHub, GitLab, Azure DevOps) that are publicly available. Second, every code repository with pipeline access is a potential attack vector. Third, external dependencies — libraries, actions, base images — execute within the pipeline context with its full permissions.
CNCF research from 2024 shows that over 60% of security incidents in cloud-native organizations originate from CI/CD access or token compromise — not from application vulnerabilities themselves.
Anatomy of a Pipeline Attack
A typical CI/CD pipeline attack doesn’t look like a movie scene. There’s no server break-in. Attackers exploit what already exists — excessive permissions, static tokens, unverified dependencies.
Scenario 1: Token compromise. A developer commits a .env file or API token to a repository. Even if the commit is deleted, the token remains visible in Git history. Attackers use scanning tools (TruffleHog, GitLeaks) and take over the token with full cloud permissions. Time from leak to exploitation: 4 minutes on average.
Scenario 2: Supply chain attack. The pipeline uses an external GitHub Action pinned to a tag, not a SHA. The action author (or someone who compromised their account) replaces the code under the same tag. The pipeline executes the modified code with full permissions.
Scenario 3: Privilege escalation via PR. In repositories with pull_request_target workflows, an attacker creates a pull request modifying the workflow. If improperly configured, the PR can run the pipeline with write permissions to the target repository — including secrets.
Each scenario is preventable. OIDC replaces static tokens. SHA pinning prevents action replacement. Proper GITHUB_TOKEN permissions close privilege escalation. But none of these controls exist by default — they must be consciously implemented. That’s hardening.
The Four Pillars of CI/CD Hardening
1. Identity and Access. Who and what can run the pipeline and modify its configuration. Includes: GITHUB_TOKEN least-privilege (read-only default), branch protection with required reviews, OIDC instead of static cloud tokens, elimination of over-privileged service accounts.
2. Secret Management. How credentials are stored, passed and rotated. Includes: dedicated vault (HashiCorp Vault, AWS Secrets Manager), automatic rotation, Git history scanning for leaked secrets, pre-commit hooks blocking secrets.
3. Execution Environment. Isolation, network permissions, resources. Includes: ephemeral runners, network access restrictions, SHA pinning of external actions and images, minimal container permissions.
4. Code and Artifact Integrity. Verification that what you deploy is what the reviewer approved. Includes: artifact signing (Cosign/Sigstore), SBOM generation (CycloneDX), provenance verification (SLSA framework), automated SAST/SCA scanning.
What Should Be the Starting Point?
Before any remediation, a diagnostic of the current state is essential. Without knowing what exists — which accounts have access, what secrets are stored and how old they are, what external dependencies execute in the pipeline — prioritization is impossible.
A well-conducted diagnostic ends with a prioritized report: what’s critical (exposure to immediate takeover), high (supply chain attack risk), medium (missing best practices, compliance gaps). Based on this, you can plan a hardening sprint — not guessing what to fix first, but working from actual risk data.