CI/CD hardening
The pipeline holds credentials, runs third-party code and publishes what goes to production. Compromising it is the shortest route to compromising everything.
What it is
CI/CD hardening is reducing what an attacker can do if they compromise the pipeline: a runner, a third-party action, a leaked token or a malicious pull request. Real supply chain incidents show the pattern: the target is no longer the application but the path that carries code to production.
Away with static secrets: OIDC
Cloud keys stored as pipeline secrets leak and live forever. The alternative is OIDC federation: the pipeline proves its identity to the cloud provider with a short-lived token, and the provider hands over temporary credentials, restricted to that repository and that branch.
permissions:
contents: read # minimum by default
id-token: write # allows requesting the OIDC token
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@<sha-completo-do-commit> # pinned by SHA
- uses: aws-actions/configure-aws-credentials@<sha-completo>
with:
role-to-assume: arn:aws:iam::123456789012:role/ci-deploy
aws-region: us-east-1
- run: ./scripts/deploy.shPipeline dependencies are dependencies too
- Pin actions and images by digest or SHA, not by a mutable tag: a tag can be repointed to malicious code.
- Least-privilege permissions for the pipeline token, defined per job.
- Beware of triggers that run fork code with access to secrets (for example, pull_request_target in GitHub Actions): treat PR input as untrusted.
- Script injection: never interpolate PR titles, branch names or commit messages directly into shell commands.
Runners and environments
Ephemeral runners (one per job, discarded at the end) prevent one job from contaminating the next and credentials from staying on disk. Shared, long-lived runners accumulate state and become targets. Separate the runners that deploy to production from those that run external code tests, and restrict outbound network access to what is necessary.
Integrity of what leaves the pipeline
Signing artifacts and recording provenance (who built it, from which commit, in which environment) lets the destination verify that what is about to run is exactly what the pipeline produced. Frameworks such as describe increasing levels of these guarantees, and tools such as cosign handle image signing.
connections on the map
- Secure infrastructure as codegoes throughCI/CD hardening
- Policy as codebecomes a gateCI/CD hardening
- Security as an internal productstandardizesCI/CD hardening
updated on 14/10/2026 · sources to go deeper · report an error
in other domains
- CI pipelines that stay fastdevopsa pipeline that works must also be a trustworthy pipeline
- Orchestration and parallel agentsvibecodingautonomous agents demand the same discipline as runners and credentials
- A08 Software or Data Integrity Failuresowaspthe pipeline is part of what must be kept intact
- CI/CDappsecthe pipeline seen as a target: the same pipeline, now hardened
- Secrets - vaults and rotationcloudsecOIDC instead of static secrets in the pipeline
Study before
Unlocks
test what you learned
Loading questions…