Install Chain Insights
← All stories

Safety Academy · Story 16 · Poisoned dependency updates

Trusted package. Untrusted Tuesday.

A routine patch release brings something the release note forgot to mention.

Estimated 4 min read

POISONED DEPENDENCY UPDATES6 scenes

A familiar package releases a small update.

Vera reviews a patch update for the team’s familiar tint-helper dependency, from 2.4.1 to 2.4.2. This example package has behaved well before. That history makes the update feel routine.

Vera
“We have used this for years.”
Illustration: A familiar package releases a small update.

A familiar name does not establish that every future version is safe.

A stolen maintainer account publishes different code.

A stolen maintainer account publishes changed code under the legitimate package name. The scammer does not need a spelling mistake this time; he has the real publishing identity.

The Scammer
“Same publisher badge. New intentions.”
Illustration: A stolen maintainer account publishes different code.

Package supply-chain attacks can use legitimate accounts and package names.

The update adds an unexpected install action.

Vera compares the update and finds an unexpected install script with an unexplained outbound connection. A colour helper suddenly wants to inspect its surroundings. She pauses rollout.

Vera
“A colour helper wants to inspect my environment?”
Illustration: The update adds an unexpected install action.

Unexpected behaviours are reasons to investigate, not proof that every install script is malicious.

Captain compares versions and origin evidence.

Captain checks available source and published-package evidence, new dependencies and origin records. Provenance can support where a release came from; it cannot prove the release behaves safely.

Captain Obvious
““Patch” describes a version. Not a safety certificate.”
Illustration: Captain compares versions and origin evidence.

A lockfile pins a version. It does not certify that the pinned version is harmless.

The team holds the suspect update.

The team holds the version and investigates in an environment without valuable secrets. If it had already executed, they would assess exposure and rotate affected credentials rather than merely pinning back.

Vera
“The build can wait. The keys cannot be unstolen.”
Illustration: The team holds the suspect update.

Use reviewed versions and monitor advisories. A test run can itself execute dependency code.

The compromised version never reaches users.

The suspect release never reaches users. A lockfile records a chosen version, not a safety verdict. The familiar package keeps its familiar name; each new release still earns review.

Vera
“Reliable package. Unreliable Tuesday.”
Illustration: The compromised version never reaches users.

Trust a reviewed release process, not merely a familiar package name.

The useful bit

A real package can publish a malicious version after a maintainer compromise.

  1. Review every new release, even from a package and a maintainer you trust.
  2. Compare the published package with its source. An unexpected script or network call is a stop sign.
  3. Hold a suspect update and test it away from real secrets. Write down which versions you reviewed.

I already did this

If the update executed, stop its rollout and alert your security team. Investigate affected machines and revoke and replace exposed service credentials from a clean setup. Rolling back cannot erase stolen secrets. Use the wallet incident guide if wallet keys were accessible.

Sources & further reading