Hardening CI/CD Against Supply-Chain Attacks

CI/CD systems are production systems with unusually powerful credentials. A compromised workflow can build artifacts, publish packages, deploy infrastructure, and silently rewrite trust.

Start with runner isolation

Shared runners are convenient, but sensitive deployments deserve runners with a narrow trust boundary. Keep production deployment runners separate from general pull request validation.

name: deploy

on:
  push:
    branches: [main]

permissions:
  contents: read
  id-token: write

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npm run build

Pin what executes

Pin third-party actions to full commit SHAs for sensitive jobs. Version tags are human-friendly, but they are also mutable references controlled by someone else.

Build provenance

Artifacts should tell a story: which commit produced them, which workflow signed them, and which environment promoted them. Provenance will not prevent every incident, but it makes tampering much harder to hide.

cosign verify-blob \
  --certificate-identity-regexp "github.com/.+/.github/workflows/deploy.yml" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  --signature app.tar.gz.sig \
  app.tar.gz

Reduce secret exposure

Prefer short-lived OIDC tokens over long-lived cloud keys. If a job can deploy with a token minted for that exact repository, branch, and environment, there is no static secret to exfiltrate.

Threat model your pipeline

Map every workflow like a production service. Identify who can trigger it, what secrets it can access, what artifact it produces, and where that artifact is deployed. Pull requests from forks, dependency update bots, and release workflows should not share the same trust level.

Questions to answer:

• Can untrusted code run before secrets are loaded?
• Can a workflow modify another workflow?
• Are artifacts signed before deployment?
• Are deployment environments protected by review?
• Can one compromised package publish to production?

Dependency controls

Pin direct dependencies where it matters, lock transitive dependencies, and review dependency scripts. Package install hooks are code execution. For production build jobs, prefer npm ci, reproducible lockfiles, and a policy for handling abandoned packages.

npm ci
npm audit --omit=dev --audit-level=high
npm run build

Incident readiness

Supply-chain incidents move quickly because the pipeline is trusted by design. Keep a revocation plan for package tokens, cloud roles, signing keys, and deployment credentials. Practice rebuilding from a known-good commit and invalidating artifacts produced during a suspicious window.

Secure pull request workflows

Pull requests are where untrusted code meets automation. Do not expose deployment credentials to workflows triggered by forked PRs. If you need preview environments, create them with restricted tokens and no production data. Require human review before running privileged workflows on contributor code.

Artifact promotion

Build once and promote the same artifact across environments. Rebuilding separately for staging and production creates gaps where dependencies or build scripts can change. Sign the artifact at build time, verify it before deployment, and keep provenance attached.

What mature teams track

Track workflow permission drift, dependency age, pinning status, failed provenance verification, secret usage by workflow, and manual deployment overrides. These metrics reveal whether pipeline hardening is improving or quietly eroding.

Review workflow changes like code

Pipeline configuration is executable infrastructure, so review it with the same seriousness as application code. Changes to .github/workflows, deployment scripts, package publish settings, and signing configuration should require owners who understand the blast radius. A one-line permission change can silently grant a workflow access to cloud deployment or package publishing.

For high-risk repositories, add policy checks that fail the build when a workflow requests broad permissions, uses unpinned third-party actions, or loads secrets before untrusted code has been isolated. These checks give reviewers a safety net and keep standards consistent across teams.

Practical maturity path

Do not try to perfect the entire pipeline in one sprint. Start with the most privileged workflows: production deploy, package publish, infrastructure apply, and release signing. Lock those down first with OIDC, protected environments, pinned actions, and artifact signing. Then move outward to test jobs, preview environments, and dependency automation.

This staged approach matters because CI/CD hardening touches developer experience. Teams are more likely to keep controls when the rollout is clear, measured, and focused on the jobs that can cause real damage.