DevSecOps Practice Hub

Pipeline Security

Harden the CI/CD system itself: runner isolation, credential scope, pinned steps and protected branches.

AdvancedPipeline SecurityInfrastructureSupply Chain

Where it fits in the lifecycle

  1. Plan
  2. Code
  3. Build
  4. Test
  5. Release
  6. Deploy
  7. Operate
  8. Monitor
  • Build Dependency scanning, image scanning, SBOM generation and signing.
  • Release Approval controls, artefact promotion and provenance.

Overview

CI systems hold deployment credentials and can write to production. They deserve the same hardening as production: least-privilege tokens, ephemeral runners, and no untrusted code running with secrets in scope.

Why it matters

Compromising CI is usually easier than compromising production and yields the same access.

How it works

  1. 01Runners are ephemeral and do not share state between jobs.
  2. 02Secrets are scoped per environment and per protected branch.
  3. 03Third-party actions and images are pinned by digest.
  4. 04Fork pull requests never run with secrets available.

Common tools

GitHubGitLabJenkinsSigstore CosignGitLabGitHubJenkinsKubernetes

Implementation examples

yamlLeast-privilege GitHub Actions job
permissions:  contents: read jobs:  build:    runs-on: ubuntu-latest    permissions:      contents: read      id-token: write    steps:      - uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
Default-deny permissions plus digest-pinned actions removes two common CI attack paths.

Best practices

  • Set default token permissions to read-only.
  • Use OIDC federation instead of stored cloud keys.
  • Never expose deployment secrets to jobs triggered by forks.

Common mistakes

  • Storing long-lived cloud credentials as CI variables.