CI/CD · Ship safely, repeatedly

What does supply-chain security mean for CI/CD?

Hardsupply chainsbomprovenanceUpdated Oct 2026
Quiz this track

Short answer

Supply-chain security means verifying every dependency and build output. Lock dependencies, pin digests, generate an SBOM, record provenance, scan for vulnerabilities, and sign artifacts so consumers can verify origin.

Your product includes code you did not write and build steps you did not author. A supply-chain attack can enter through a compromised package, a malicious build action, a tampered base image or a stolen signing key.

  • Commit lockfiles and use a private proxy or allowlist for critical dependencies
  • Pin base images and CI actions to immutable digests or SHAs
  • Generate an SBOM so you can answer which components are in a release
  • Record build provenance that links the artifact to source and builder
  • Sign artifacts and verify signatures before deployment
  • Scan dependencies and images continuously, not only at release time
sh
cosign sign --key cosign.key registry.example.com/app@sha256:abc123
cosign verify --key cosign.pub registry.example.com/app@sha256:abc123
syft registry.example.com/app@sha256:abc123 -o spdx-json > sbom.json
Scanning alone is not supply-chain security. A clean vulnerability scan says nothing about whether the artifact was built from the source you think, by the builder you trust, with the dependencies you expect.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

  1. 1What is an SBOM and what do you do with it?
  2. 2What does build provenance prove?
  3. 3How do you respond to a critical vulnerability in a transitive dependency?
  4. 4Why is a lockfile not sufficient on its own?

Say it in the interview

Supply-chain security covers everything that goes into an artifact: dependencies, base images, build tools and the build itself. I lock and pin inputs, generate an SBOM, record provenance and sign the artifact, then verify those signatures before deployment. I also scan continuously so a newly disclosed vulnerability in a transitive dependency is found. The goal is to know exactly what is in a release and be able to prove where it came from.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Related questions

Reading is step one

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live CI/CD mock interview and get scored feedback on depth, clarity and confidence.