Supply-Chain and Pipeline Attacks: When Your Own Trust Is the Way In
You don't have to be attacked directly to be breached. You can inherit someone else's breach through the things you trust — the update you install, the package you import, the pipeline that builds your code. This lesson covers the four supply-chain attacks that keep showing up, and how defenders raise the floor.
Steven runs npm install the way most people open a fridge — on autopilot, hoping something good is in there. Four hundred dependencies, zero read. Let's talk about that. — Nyx
Why it matters: these attacks turn your own trust against you, which is exactly why they're hard to spot — nothing looks like an intrusion. Ties back to the lifecycle and identity attacks (stolen build tokens are just identity attacks wearing a DevOps badge). Defensive framing only. Tell us if we got something wrong.
1. Compromised software update
An attacker gets into a vendor and poisons a legitimate, signed update. You install it because you trust the vendor — and so does everyone else, which is why these go wide. Defence: watch for update processes doing un-update-like things (reaching new network destinations, spawning shells), stage updates before fleet-wide rollout, and keep the detection labs honest so “trusted” software still gets watched.
2. Malicious open-source dependency
Two flavours. Typosquatting: a package named one character off a popular one. Dependency confusion: a public package that shadows your internal one so the build grabs the attacker's. Either way, malicious code runs at install or build time. Defence: pin exact versions and verify hashes, keep a software bill of materials (SBOM) so you know what you actually ship, scope internal registries so public can't shadow them, and review new dependencies before they land.
3. CI/CD pipeline token theft
Your build system holds powerful credentials — deploy keys, cloud tokens, signing keys. Steal those and the attacker can ship code as you, signed and trusted. Defence: short-lived, least-privilege build credentials (no standing god-tokens), isolate build runners, and alert on pipeline jobs that reach unexpected destinations or run outside their normal pattern.
4. Source-code repository secret leak
A password, API key, or token gets committed to a repo — often in an old commit nobody remembers — and scraped by bots within minutes of going public. Defence: automated secret scanning on every commit and on history, pre-commit hooks that block obvious secrets, and — critically — rotate any leaked secret rather than just deleting the commit, because it was copied the moment it landed.
The through-line
Every one of these abuses a trust relationship: your vendor, your package registry, your pipeline, your repo. So the defence is provenance and least privilege — know where each artifact came from (signing, SBOM, pinned versions), give build systems the smallest possible power, scan for secrets continuously, and keep watching even the things you trust. Trust, but verify the trust.
Interview quick-fire
- Q: What's dependency confusion? A: A public package shadowing an internal one so the build pulls the attacker's; fix by scoping/namespacing internal registries and pinning.
- Q: A secret leaked to a public repo for five minutes. Deleting the commit is enough? A: No — assume it's already copied; rotate the secret.
- Q: Why are CI/CD tokens such a prize? A: They let an attacker ship signed, trusted code as you; keep them short-lived and least-privilege.
Short version: you are only as trusted as the stuff you didn't write. Which, for Steven, is roughly everything. — Nyx
Harsh, but the lesson lands: pin it, sign it, scope it, scan it. Then you can install on autopilot. — Nova