4 MIN READ
Picture the standard open source flow. Developer runs npm install, pulls a hundred transitive packages, builds, ships. Most of those packages were fine yesterday. Today, the attacker has realised that one malicious package in that graph is enough to walk off with the credentials, the keys, and the build pipeline. Typosquats, account takeovers, post install hooks, malicious GitHub Actions. The pattern has matured. The frequency has increased. The defender who still treats the open source dependency as trustworthy has accepted a risk the attacker has learned to exploit.
What the attack actually looks like in 2026
Five patterns show up in production right now, in roughly this order of frequency.
1. The typosquat. Attacker publishes a package with a name one character off from a popular one, or substitutes a visually similar Unicode character. The build picks it up, the hook runs in the install context, and the environment variables, the .npmrc, the .aws/credentials walk out the door. The cheapest way to monetise the typosquat and the easiest to overlook.
2. The name confusion attack. Attacker takes over an existing package, either by registering the abandoned name or by convincing the original maintainer to hand over ownership. A new version ships with a post install hook. Every install of that package, the legitimate one included, now exfiltrates.
3. The malicious GitHub Action. The action runs in CI, on every commit, on every pull request. The action has access to the secrets by default. The action exfiltrates them.
4. The compromised maintainer account. Phish the npm or PyPI credentials, publish a new version of a legitimate package, wait for the downloads to roll in. Same shape as the name confusion, just faster.
5. The typosquatted Docker image. Similar name to the official one, backdoored binary inside, outbound connection to a command and control server on first run. Less common than the package variants, but the impact compounds because the image is the runtime, not just the build.
What the defence looks like
Three moves matter, in priority order.
1. Pin and verify everything. Lock the package versions, the container image digests, the GitHub Action SHAs. Pinning decides whether the supply chain uses what the developer intended or whatever the upstream published last night. Verification decides whether the artifact has been tampered with between the upstream and the build environment. Sigstore, SLSA provenance, software bill of materials tools. The work is not free, and it falls on the engineering org to do it.
2. Run a private package registry as a proxy. The proxy enforces the allowlist, catches the typosquat before it reaches the build, and gives the platform org a single place to see what is actually being installed. The cost is operational rather than licensing, and the platform org is the one that has to ship it.
3. Scan everything in CI. Vulnerability scanner, secret scanner, malware scanner, SBOM generator. The scanning catches the package that slipped through, and the AppSec team is the one that has to wire it in and triage the noise. None of this is a one-time setup. The threat shifts, the scanners shift with it, the AppSec team shifts with the scanners.
What to do this quarter
Three starting points, in the order they tend to land.
1. Audit the top 20 dependencies. Look for the typosquats, the abandoned packages, the unmaintained packages. The audit takes a week, the audit produces the replacement list, and the engineering org has been avoiding the audit for a reason. Do it anyway.
2. Stand up the private registry. This one belongs to the platform org. Budget for the operational cost, ship it this quarter, and the rest of the supply chain controls start to make sense.
3. Wire the scanning into the existing CI. The AppSec team has wanted this wired in for years, and the AppSec team is the one that has to integrate it with whatever the engineering org is already running. Plan for the noise. Plan for the false positives. The wire-up pays for itself the first time it catches a real package.
The bottom line
Pin everything, proxy through a private registry, scan in CI, audit the top 20 dependencies. The defender who treats the open source supply chain as a trusted layer is the one who will hand the keys to the attacker within the year.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
