How would you protect your build pipeline from a supply chain attack?
What they are really testing: Whether you think about the pipeline as an attack surface rather than only as a delivery mechanism. A pipeline holds production credentials and runs third-party code, which makes it one of the highest-value targets you own.
A real interview question
How would you protect your build pipeline from a supply chain attack?
What most people say
drag me
“We scan our images for vulnerabilities before deploying them.”
Scanning finds known vulnerabilities in what you built. It does nothing about a compromised build step, a malicious CI action, a dependency swapped after review, or an artifact tampered with between build and deploy, which are the actual supply chain attacks.
The follow-ups they ask next
What specifically goes wrong with using a version tag for a CI action?
Tags are mutable and usually point at a branch or a moving release. Whoever controls that repository can change what the tag points to, and your next run executes new code with your production credentials, with no diff for you to review.
How does signature verification actually stop an attack at deploy time?
An admission controller checks the signature against your key before allowing the workload. So even an attacker who obtains registry push access cannot get their image to run, because they cannot produce a valid signature.
A critical CVE drops in a common library. Walk me through your first hour.
Query SBOMs to find every service that includes it and at what version, rank by exposure and reachability, patch the internet-facing reachable ones first, and communicate a status. Without SBOMs the first hour is spent just enumerating.
Is pinning by digest not a maintenance burden?
Yes, which is why it needs automation: a bot that proposes digest bumps as reviewable pull requests. That keeps updates flowing while every change remains an explicit, reviewed event rather than an invisible one.
What the interviewer is listening for
- Treats the pipeline as production infrastructure
- Distinguishes scanning from provenance
- Names SBOM as an incident-response tool, not compliance paperwork
- Pins third-party actions by commit sha
What sinks the answer
- Equates scanning with supply chain security
- Uses mutable tags for actions and base images
- No artifact signing or verification
- Long-lived credentials in CI
If you genuinely do not know
Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.
“The pipeline is [production: it holds deploy credentials and runs third-party code]. So: [pin dependencies and base images by digest, not mutable tags], [pin and allowlist CI actions since they are code with your credentials], [sign artifacts and verify at admission], [generate SBOMs so you can answer "are we affected" in minutes], and [use short-lived federated credentials].”
Keep going with security
Junior
Your pipeline needs credentials to deploy to production. How do you handle that safely?
Mid
Your vulnerability scanner reports 200 CVEs in a production image. How do you handle it?
Mid
How would you rotate a database password used by 12 running services with no downtime?
Mid
Your deploy role has full administrator access because narrowing it kept breaking things. How do you fix that properly?
Senior
Compliance requires that every production change is approved and auditable. How do you keep deploying daily?
Senior
Design a CI/CD system for 15 microservices owned by 4 teams deploying several times a day.
Knowing the answer is not the same as recalling it under pressure
Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.
Start free