Back to Blog
Threat Landscape

Supply Chain Attacks: When Trusted Software Becomes the Threat

From SolarWinds to npm package compromises, supply chain attacks turn your trusted vendors into your most dangerous attack vector. Here's how they work and how to defend.

EEmil GheoneaJune 18, 20268 min read

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 (reqeusts instead of requests).
  • 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

  1. Implicit trust. Updates from vendors and packages from package managers are assumed safe.
  2. Code signing is not enough. If the attacker controls the signing infrastructure, signed payloads are still malicious.
  3. Massive blast radius. Compromise one vendor and reach every one of their customers.
  4. Delayed detection. Backdoors often dwell for months before activation.
  5. 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)

  1. Lock down the build system. Treat your CI as production. Limit who can modify pipelines.
  2. Sign your artifacts and protect signing keys with hardware modules.
  3. Use reproducible builds so anyone can verify the binary matches the source.
  4. Run dependency audits in CI (npm audit, pip-audit, govulncheck) — and act on the results.
  5. Enable two-person review for any change to the build pipeline or package metadata.
  6. 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.

E

Emil Gheonea

Software Developer & Security Enthusiast

Full-stack developer with a focus on cybersecurity tooling and infrastructure. I built VirusPurge to make fast, private file scanning accessible to everyone — and I write about security topics to keep the knowledge sharp.

Connect on LinkedIn