Supply Chain Attack
- •
What it is
- •
A form of targeted attack where malicious code is introduced into otherwise legitimate software — either directly into a project, or indirectly through a third-party dependency — so that it spreads to everyone downstream who installs or updates that software.
- •
- •
Why it matters
- •
It's one of the hardest attacks to defend against, because you're trusting not just the software you directly chose, but every dependency and every contributor behind it. A single compromised link anywhere in that chain can silently compromise everyone who trusted the end product.
- •
- •
How it works
- •
Typically happens one of three ways: a contributor/employee already inside a project abuses their position to add malicious code; an outside party coerces a developer into adding it; or an attacker identifies a widely-used dependency and infiltrates it, knowing many downstream projects will pull it in automatically.
- •
Mitigation is about reducing trust risk rather than eliminating it: favor software with a long track record and many contributors (harder to quietly compromise), built via trusted/public build infrastructure (e.g. GitHub Actions) rather than a developer's own machine, with signed commits/releases (creating an audit trail) and clear, meaningful commit messages.
- •
- •
Example
- •
In 2017, the Ukrainian accounting software M.E.Doc was infected with the NotPetya ransomware, built on the NSA-developed EternalBlue exploit. Anyone who downloaded a legitimate update to M.E.Doc got ransomware along with it — the attack eventually affected over 2,000 companies across multiple countries, none of whom had done anything wrong beyond trusting their accounting software's update.
- •
- •
Related
- •
Cards
- •
Why are supply chain attacks unusually hard to defend against?
- •
They compromise trust indirectly — through a dependency or contributor — so protecting yourself requires trusting the entire chain behind a piece of software, not just the software itself.
- •
- •
Name two concrete signals that reduce (not eliminate) supply chain attack risk in a piece of software.
- •
E.g. a long track record with many contributors, signed commits/releases, and builds produced via trusted public infrastructure rather than a developer's own machine.
- •
- •