What is a software supply chain attack?

How does a supply chain attack actually work?

The attacker does not break into your network. They get their code into something you install on purpose: an npm or PyPI package, a browser extension, an IDE plugin, or a CI step. When you build or run it, their code runs with your trust and your access.

The most effective version ships clean first. A package or extension earns installs and a good reputation, then a later update adds the malicious behavior - a new outbound request, a broadened permission, or a remote code path. Day-one review passes; the danger arrives on update.

Why are update channels the weak point?

A team reviews a dependency once, pins it, and moves on. The version vetted in January is rarely the version running in June. Attackers exploit exactly this gap: a stolen publisher account or signing key pushes a poisoned update to existing, trusting installs.

Extuno treats the diff between two versions as the unit of detection. Instead of asking is this package bad, it asks what did this update change, and is any of it dangerous - the signal that catches the poisoned-update class.

What are the common supply chain attack techniques?

Typosquatting and dependency confusion trick a resolver into installing the wrong package. Install hooks (npm postinstall, Python setup.py) run code before anything is imported. Maintainer takeover and repojacking seize a trusted name. Update-channel compromise poisons a known-good project after the fact.

How do you detect supply chain attacks?

Read every version three ways. Static analysis reads the code without running it. A dynamic sandbox runs the artifact in a network-segmented micro-VM and records what it really does - endpoints, payloads, API calls. Cross-version diffing flags the exact change an update introduced. Together they surface the behavior, the destination, and the evidence.