Supply chain attack

Getting breached through code you trusted and installed: a package, a plugin, a build tool, a vendor. Your own pipeline delivers the attack.

an npm package went roguehacked through a library I installedmalicious dependencycompromised packagesomeone hijacked a package I depend onsuply chain attackthe vendor got breached and it hit uspoisoned update

See it

Live demo coming soon

What it is

You get breached through something you already trusted and installed. The attacker does not knock on your front door, they compromise a package, a plugin, a CI action, a browser extension, or a vendor, and your own build pipeline carries the payload in. Canonical cases: 'event-stream' (2018, maintainer handed the keys to a stranger), SolarWinds (2020, poisoned vendor update), Codecov (2021, tampered bash uploader), and the xz-utils backdoor (2024, a patient fake maintainer).

The usual entry paths are boring: an install script that runs on 'npm install', a maintainer account without 2FA that gets phished, a typosquatted package name, dependency confusion where a public package outranks your internal one, or a GitHub Action pinned to a mutable tag. Defenses that actually move the needle: commit the lockfile, pin actions to commit SHAs, run CI installs with '--ignore-scripts', keep an SBOM, and treat every new dependency as a decision rather than a reflex.

Misconception: popularity equals safety. Downloads only mean the blast radius is bigger when the package falls. The other trap is thinking a lockfile saves you: it pins versions, but it happily reinstalls a version that was already malicious, and postinstall scripts still run with your developer's credentials and network access.

Ask AI for it

Harden this repository against supply chain attacks and show me the diff. Commit a lockfile and enforce it in CI with a frozen/clean install, run installs with '--ignore-scripts' where the build allows, pin every GitHub Action and Docker base image to an immutable commit SHA or digest, and enable provenance/signature verification if the registry supports it. Add a CI step that generates an SBOM and one that diffs newly added dependencies in a pull request so a human reviews them. Then list every direct dependency with its maintainer count, last publish date, and whether it runs install scripts, and flag the ones that look abandoned or typosquat-adjacent.

You might have meant

dependency vulnerability scanningtyposquattingdependency confusionsbomblast radius

Go deeper