How to Prevent Supply Chain Attacks in CI/CD

Supply Chain Defense Starts With the Build Path

Supply chain attacks are popular because they scale. Attackers compromise one dependency, one plugin, one CI step, or one release mechanism and inherit trust they did not have to build themselves.

SolarWinds showed what a compromised build path can do. Codecov showed what a leaked CI secret path can do. The xz backdoor showed how patient social engineering can poison trusted software upstream. More recently, incidents in the GitHub Actions ecosystem reminded everyone that workflow dependencies are part of the same problem.

The right defense model for CI/CD is layered, not aspirational.

1. Trust Fewer Upstream Components

Inventory what your build depends on:

• package registries
• third-party actions and plugins
• container base images
• shared workflows
• build runners and images
• artifact stores

If you do not know that list, you do not know your supply chain.

2. Pin What Can Be Pinned

Use immutable references where possible:

• lockfiles for packages
• commit SHAs for actions
• digests for images
• version pinning for providers and modules

Pinning is not perfect, but it makes silent drift harder.

3. Verify Artifacts, Not Just Build Them

Artifact signing and provenance are not optional nice-to-haves anymore.

Practical baseline:

1. generate SBOM
2. sign artifact or image
3. attach provenance
4. verify before deploy

That is where SLSA and Sigstore help operationalize trust.

4. Protect the Pipeline Secrets and Identity Path

Most supply chain defenses collapse if attackers can simply steal deploy credentials from CI.

Do this:

• use OIDC or short-lived credentials
• restrict which branches and workflows can assume roles
• keep secrets out of untrusted jobs
• rotate aggressively after suspicious events

5. Reduce Runner Trust and Persistence

Ephemeral runners are not only cleaner; they are easier to trust.

If you use long-lived self-hosted runners, you must think about:

• cross-job contamination
• malicious persistence
• credential residue
• access to cached artifacts

6. Watch for Workflow and Dependency Drift

Useful alerts include:

• new external action introduced
• action reference changed from SHA to tag
• build image changed unexpectedly
• signature verification skipped or fails open
• reusable workflow source changed

7. Run Tabletop Exercises for Supply Chain Failure

Ask realistic questions:

• What if a popular workflow dependency is compromised today?
• What if a build secret leaked last week and we just learned it now?
• Which artifacts from the past 30 days can we confidently verify?

If the team cannot answer those questions, the process still depends on fragile trust.

Supply Chain Checklist for CI/CD

• build dependencies inventoried
• actions, images, and modules pinned
• SBOM generated for release artifacts
• provenance and signing enabled
• short-lived CI credentials used
• runners isolated or ephemeral
• workflow changes monitored
• response plan exists for compromised dependency or build path

Further Reading

• SLSA Framework
• Sigstore
• NIST Secure Software Development Framework
• OWASP Software Supply Chain Security Cheat Sheet
• CycloneDX

Related SecureCodeReviews guides:

• Software Supply Chain Security
• CI/CD Pipeline Security
• GitHub Actions Security Best Practices

Supply chain defense is not about eliminating trust. It is about making trust explicit, verifiable, and much harder to abuse silently.