CI/CD Security Checklist
CI/CD pipelines are one of the most trusted components in a modern software delivery stack. They have read access to your source code, write access to your artifact registries, and deployment access to your production environments. That trust is operationally necessary, and it makes them high-value targets. The threat model for CI/CD is distinct from application security. The goal of an attacker…
- OIDC federation eliminates long-lived CI credentials, it is the highest-leverage single security change available
- Pin GitHub Actions to commit SHAs, not tag names, tags are mutable and can be silently changed
- Artifact attestation creates verifiable provenance that links a deployed artifact to the exact pipeline run that produced it
- Secret scanning must be build-blocking, not just notifying, a non-blocking alert is detection theater
- Pipeline audit logs only matter if they are shipped to a SIEM, logs that live only in the CI system are inaccessible during incidents
Secrets Security: The Highest-Impact Category
Secrets in CI/CD pipelines fail in two ways: they get committed to source code, or they get exposed through environment variable leakage in build logs. Both are entirely preventable with the right architecture, but preventing them requires structural decisions, not just policy. The structural decision that eliminates most long-lived credential exposure is OIDC federation. GitHub Actions, GitLab CI, and CircleCI all support OIDC token exchange with AWS, GCP, Azure, and HashiCorp Vault. Instead o
Permissions Hardening: Least-Privilege Job Tokens
GitHub Actions workflows have a default permissions model that is more permissive than most teams realize. The 'GITHUB_TOKEN' granted to a workflow job has, by default in many organization configurations, write access to repository contents, packages, and deployments. A workflow that only needs to run tests does not need write access to anything, but unless you explicitly scope it, that is what it has. The correct operational pattern is to set 'permissions: read-all' at the workflow level and e
Supply Chain Security: Pinning, SBOMs, And Signing
Supply chain attacks target the dependencies and actions that your pipeline executes. A malicious update to a GitHub Action, a compromised PyPI package, or an NPM dependency with a typosquatted name can execute arbitrary code inside your pipeline with full access to your build environment, secrets, and deployment credentials. The controls are pinning, generating SBOMs, and signing artifacts. Pinning GitHub Actions to full commit SHAs, 'uses: actions/checkout@v4' becomes 'uses: actions/checkout@
Frequently asked questions
- What is the single most impactful CI/CD security change for most teams?
- Replacing long-lived CI credentials with OIDC federation. Most pipelines are running with static AWS access keys, GCP service account JSON keys, or long-lived API tokens stored as repository secrets. Every one of those is a persistent credential that can be leaked, stolen, or forgotten after rotation. OIDC federation eliminates the credential enti…
- How do I prevent a malicious GitHub Action from stealing my secrets?
- Pin all Actions to full commit SHAs, not tag names. Tag names are mutable, 'actions/checkout@v4' points to whatever commit that tag references today, which can be changed by anyone with access to the upstream repository. A full SHA pin ('actions/checkout@<sha>') is immutable. Additionally, set explicit job-level permissions so that even a compromi…
- What is SLSA and do I actually need it?
- SLSA (Supply chain Levels for Software Artifacts) is a framework that defines levels of supply chain security assurance, from basic source version control (Level 1) to fully hermetic, reproducible builds (Level 4). For most teams, achieving SLSA Level 2, which requires pipeline provenance attestation and artifact signing, is the practical target t…
- What should pipeline audit logs capture that most teams miss?
- Two things: outbound network connections made by pipeline jobs, and the exact workflow definition version (commit SHA) that was executed. Most CI logs capture inputs and outputs but not network behavior, which is where exfiltration and supply chain callback activity appears. And knowing a run used 'the workflow' is insufficient for incident respon…