One bad import: how supply-chain compromises start.

The shape of the attack

Modern applications are mostly other people's code. A typical service pulls in a few direct dependencies and hundreds of transitive ones - packages your packages depend on, written by people you have never heard of, updated on schedules you do not control. Each one runs with your build's privileges, and many run code at install time before you have executed anything at all.

So the attacker's question is simple: why breach a hardened target when you can compromise one small library it trusts? The delivery routes repeat: typosquats (a package one keystroke away from the real name), hijacked maintainer accounts (one phished login upstream), malicious install scripts (payload runs on install), and deep transitive dependencies nobody on your team has ever read.

What history keeps teaching

• left-pad, 2016. Eleven lines of code were unpublished from a registry and build pipelines across the industry stopped. Not an attack - a demonstration of how much invisible trust one tiny package carries.
• event-stream, 2018. A tired maintainer handed a popular package to a helpful stranger. The stranger shipped a payload aimed at one specific cryptocurrency wallet. Millions of downloads carried it; almost nobody was the target; everybody ran it.
• xz-utils, 2024. A multi-year social-engineering campaign earned commit rights to a core compression library and smuggled in a backdoor aimed at SSH. It was caught - by one engineer investigating a half-second of slowness - just before reaching mainstream stable releases. The near-miss that rewrote threat models.

Three different routes, one lesson: the trust is the vulnerability.

Defenses that work (and are boring)

1. Lockfiles, committed and enforced. Builds install exactly what was reviewed - versions and hashes - not whatever the registry serves today.
2. Fewer dependencies. The strongest control on this list. Every dependency is a standing invitation. If it is under fifty lines, write it yourself.
3. Install scripts off by default. Most package managers can refuse lifecycle scripts unless allow-listed. That single policy kills a whole payload class.
4. A cooldown for new versions. Compromised releases are usually caught within days. Pinning plus a short quarantine before adopting fresh versions lets someone else be the canary.
5. An SBOM you can query. When the next advisory lands, "are we affected?" should take minutes, not a weekend of grepping.
6. Scoped credentials in CI. The build that installs untrusted code should not also hold production keys. Assume the install step is hostile and design outward from there.

The honest part

You will not review every line of every dependency. Nobody does; pretending otherwise produces checkbox theater. The achievable goal is different: make the compromise survivable. Fewer packages, pinned versions, no install-time execution, credentials that a poisoned build cannot reach, and an inventory that answers questions fast.

The chain will carry a bad link eventually. Decide now how far it can pull.

Trust is transitive. Privilege should not be.