Securing your CI/CD pipeline: the attack path most teams forget

A CI/CD pipeline has everything an attacker wants: cloud credentials, signing keys, access to source code, and the power to push code straight to production. Compromise the pipeline, and you don't need to break the application at all.

How pipelines get compromised

• Leaked secrets: tokens printed in build logs, stored in repository files, or available to every branch and pull request
• Untrusted pull requests: workflows that run code from forks with access to secrets
• Third-party actions and plugins: referenced by a movable tag like @v3, so a compromised upstream release runs in your pipeline
• Over-privileged tokens: pipeline credentials that can do far more than deploy one service
• Shared or self-hosted runners: build machines that keep state between jobs or sit on internal networks

Practical hardening steps

1. Use short-lived credentials. Replace stored cloud keys with OpenID Connect (OIDC) federation, so the pipeline gets temporary credentials for each run.
2. Scope secrets tightly. Limit production secrets to protected branches and environments with required approvals.
3. Pin third-party actions to a full commit SHA rather than a tag, and review what they do before adding them.
4. Set minimal default permissions for pipeline tokens (in GitHub Actions, permissions: read-all or narrower) and grant more per job only where needed.
5. Be careful with fork pull requests. Don't expose secrets to workflows triggered by untrusted code.
6. Use ephemeral runners that are destroyed after each job, and keep self-hosted runners off sensitive networks.
7. Scan in the pipeline. Add secret scanning, SAST, SCA and IaC checks, and generate an SBOM for each release.
8. Protect the main branch: required reviews, signed commits where practical, and no direct pushes.

We review pipelines as part of our application security assessments, and can set up scanning in your CI/CD for you. Request a quote.