What Is a Supply Chain Attack?
A supply chain attack compromises an organisation not by targeting it directly, but by targeting one of the third parties it depends on. The attacker poisons a trusted vendor's product, then waits for the vendor's customers to install it.
Because the malicious code arrives signed, packaged, and through your normal update channels, almost every traditional defence assumes it is safe.
The Defining Cases
SolarWinds Orion (2020)
State-sponsored actors compromised the build pipeline of SolarWinds — a major network monitoring vendor — and inserted a backdoor (codenamed Sunburst) into a routine update. The update was downloaded by an estimated 18,000 organisations including US government departments, Fortune 500 companies, and security vendors. The backdoor lay dormant for two weeks, then beaconed out to attacker infrastructure.
MOVEit Transfer (2023)
The Cl0p ransomware group exploited a zero-day SQL injection vulnerability in MOVEit, a managed file-transfer product used by hundreds of large organisations. Customer data from more than 2,500 companies was exfiltrated.
npm and PyPI Package Compromises
In the open-source ecosystem, attackers have:
- Typo-squatted popular packages (
reqeustsinstead ofrequests). - Compromised maintainer accounts and pushed malicious updates to legitimate packages with millions of downloads (event-stream, ua-parser-js, color, faker).
- Used dependency confusion to trick build systems into pulling a malicious public package instead of an intended internal one.
Why Supply Chain Attacks Are So Effective
- Implicit trust. Updates from vendors and packages from package managers are assumed safe.
- Code signing is not enough. If the attacker controls the signing infrastructure, signed payloads are still malicious.
- Massive blast radius. Compromise one vendor and reach every one of their customers.
- Delayed detection. Backdoors often dwell for months before activation.
- Plausible deniability. The vendor is also a victim, complicating attribution and remediation.
How to Defend (As a Consumer of Software)
1. Inventory Your Dependencies
You cannot defend what you do not know you have. Maintain a software bill of materials (SBOM) for production systems — direct and transitive dependencies.
2. Pin and Verify
- Pin dependency versions and check hashes (
package-lock.json,Pipfile.lock,go.sum). - Verify checksums and signatures where available.
- Subscribe to security advisories for everything you use.
3. Minimise Your Footprint
Fewer dependencies, fewer vendors, fewer integrations → smaller supply chain attack surface.
4. Network Segmentation
A compromised vendor agent should not be able to reach your entire internal network. Place vendor tools in their own segments with strict egress filtering.
5. Monitor Outbound Traffic
Many supply chain backdoors beacon out to C2 servers. Egress monitoring and DNS logging can catch these calls even when the binary itself looks clean.
6. Patch — But Cautiously
Staged rollouts (canary → 10% → 100%) of vendor updates give you time to catch a bad update before it hits production.
How to Defend (As a Producer of Software)
- Lock down the build system. Treat your CI as production. Limit who can modify pipelines.
- Sign your artifacts and protect signing keys with hardware modules.
- Use reproducible builds so anyone can verify the binary matches the source.
- Run dependency audits in CI (npm audit, pip-audit, govulncheck) — and act on the results.
- Enable two-person review for any change to the build pipeline or package metadata.
- Use scoped publishing tokens, never long-lived ones.
The Hard Truth
You can do everything right and still be hit by a supply chain attack — because you depend on someone who got it wrong. The goal is not to eliminate the risk (impossible) but to detect it faster and limit the blast radius when it happens. Assume breach, log generously, and design networks so that one compromised vendor cannot become a complete catastrophe.