extuno
What is a software supply chain attack?
Instead of attacking you directly, a software supply chain attack compromises you through a dependency, a build system, or an update channel you already trust. One poisoned release reaches every downstream user at once.
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 version adds a new outbound request, broadens a permission, or opens 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. It does not ask whether the package is bad. It asks what this update changed, and whether any of it is dangerous.
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 the endpoints it contacts, the payloads it sends, and the API calls it makes. Cross-version diffing flags the exact change an update introduced.