pipeline-security

Pipeline Security

CI/CD pipelines are one of the highest-leverage attack targets in most organizations, and defended far less than production itself: a compromised pipeline can push malicious artifacts straight to production, exfiltrate every secret it touches, and do it with legitimate-looking commits and green checkmarks. Treat the pipeline with the same rigor as production infrastructure — because functionally, it has more power than production, it's what creates production.

If your pipeline can deploy to production, your pipeline security posture is your production security posture.

A pipeline that can push to production must be defended as rigorously as production itself — it is a privileged system, not a convenience layer.

For Cosign container signing, SBOM generation, and SLSA attestation snippets, read references/supply-chain-security.md.

1. Give runners the least privilege the job actually needs

A CI job that only runs unit tests has no business holding cloud credentials capable of deploying to production, yet shared runner configurations often grant broad permissions "for convenience" across every job type. Scope credentials per job: test jobs get no cloud access at all, build jobs get registry push access and nothing else, deploy jobs get deploy-scoped credentials to exactly the environment they target. A compromised test-stage dependency should not be able to reach production.

• Test/lint jobs: no cloud credentials, no network egress beyond package registries.
• Build jobs: registry push, nothing broader.
• Deploy jobs: scoped to one environment, ideally via short-lived, environment-specific credentials.

Done when: no single CI job holds credentials for more than the one environment or system it's actually responsible for touching.

2. Use OIDC federation instead of long-lived static credentials

A long-lived cloud access key stored as a CI secret is a standing liability — it doesn't expire on its own, it can leak through logs or a misconfigured job, and revoking it requires someone to notice and act. OIDC federation (GitHub Actions ↔ AWS/GCP/Azure via workload identity) issues short-lived, scoped credentials per job run, tied to verifiable claims about which repo and workflow requested them — nothing persists to leak after the job ends.