Safeguard
Software Supply Chain Security

Nobody Is Exploiting Your Dependencies. They Are Logging Into Them.

keyv, Mastra, Nx, AsyncAPI, jscrambler. Five of 2026's largest supply chain incidents, and not one involved a software vulnerability. The exploited weakness every time was a maintainer account.

Shadab Khan
Security Engineer
6 min read

Line up the largest software supply chain incidents of 2026 and check what was exploited in each.

IncidentExploited weaknessCVE
keyv / cacheable, AugustMaintainer GitHub accountNone
Mastra npm scope, JuneDormant contributor accountNone
Nx Console extension, MayPrior compromise of developer systemsNone
AsyncAPI CI hijack, JulyPipeline trust relationshipNone
jscrambler npm, JulyPublishing credentialsNone

Zero CVEs. Not one of these was a software defect. In every case the software worked exactly as designed, and an attacker used a legitimate publishing path with legitimate credentials.

That is a threat model most security programmes are structurally unable to address, because the entire dependency-security toolchain was built to answer a different question.

Why CVE-driven tooling is blind here

Software composition analysis answers: does any dependency have a known vulnerability? It compares your resolved versions against a vulnerability database.

Malicious-by-design code produces no database entry. There is no CVE for "this version contains a credential stealer," because CVE describes flaws in software, and this software has no flaw — it does precisely what its author intended. By the time an advisory exists, the package has usually been unpublished and the campaign is over.

Timing makes it worse. The keyv worm reached 444 package names within hours. Advisory publication, database ingestion, and scanner refresh cycles are measured in days. The window in which a scanner could have helped closed before the scanner knew anything.

This is not a criticism of SCA. It is a statement about scope: SCA covers accidental vulnerabilities; it does not cover deliberate malice. Both are real, and only one of them is what took down the npm ecosystem twice this quarter.

What a maintainer account actually controls

The asymmetry is severe and worth stating in concrete terms. A single npm account with publish rights typically controls:

  • Every version of every package it maintains, forever forward
  • Installation on every machine that resolves those packages
  • Code execution on those machines, if install scripts are enabled
  • Whatever those machines hold: cloud credentials, source, CI secrets, signing keys

The keyv account owned packages totalling over two billion monthly downloads. That is more reach than most CVEs ever achieve, controlled by one set of credentials, protected by whatever 2FA that individual chose to enable.

And these accounts are held by volunteers. Unpaid maintainers, maintaining critical infrastructure in their spare time, with no security budget, no corporate 2FA policy, no SSO, no monitoring, and no incident response support. The mismatch between the value of the asset and the resources defending it is the entire structural problem.

Detection that works on this threat model

Since the vulnerability database will not help, the signals that do:

Behavioural delta between versions. A caching library that newly declares a preinstall hook, newly downloads a binary, or newly reads ~/.aws has changed behaviour in a way that is anomalous on its face. This is the highest-value signal because it is available immediately — at publish time, before anyone has named the campaign.

Publishing anomalies. A package published outside its maintainer's normal hours, from a new IP or country, after a long dormancy, or ten packages published within one minute. Publish metadata is a rich detection surface and it is barely used.

Provenance and attestation. Was this published through a trusted-publishing workflow with a verifiable attestation, or by a token from an unknown location? Provenance turns a publishing event into something checkable.

Dependency update velocity. An organisation that auto-merges dependency updates within hours has structurally more exposure than one with a 72-hour soak. Most of these campaigns are detected and unpublished within a day, so a short delay converts most of them into a non-event.

Install-time telemetry. Credential-path access from a dependency install step is close to always wrong, regardless of which package or campaign is responsible.

What to change

Add a soak period to dependency updates. Not for security patches, where speed matters — for routine version bumps. A 24-to-72-hour delay costs nothing and avoids the majority of these campaigns, because the ecosystem's detection-and-unpublish cycle is faster than that.

Audit your own publish rights. The Mastra incident began with a forgotten contributor account holding unrevoked publish rights. Every organisation publishing packages has this. Enumerate who can publish what, and remove everyone who does not currently need to.

Require FIDO 2FA on publishing accounts. Phishing-resistant, and npm is deprecating TOTP in favour of it anyway.

Eliminate long-lived publish tokens. Worm propagation runs on standing credentials. OIDC trusted publishing removes the thing being stolen.

Support the maintainers you depend on. Less concrete, but the asymmetry above is not solvable by any one company's controls. Funding, contributing security work, and taking on maintenance burden for critical dependencies are the only interventions that address the actual cause.

How Safeguard helps

Behavioural delta analysis as a first-class signal. Safeguard evaluates version-over-version behaviour for packages, containers, models, IDE extensions, and MCP servers — install hooks, filesystem access, network destinations, embedded binaries. For malicious-by-design code, this is the only signal that exists on the timescale these campaigns run at, since no CVE will ever be issued.

Publishing provenance and anomaly checks. Safeguard evaluates whether dependencies were published through trusted publishing with verifiable attestations, and flags publishing patterns that break a package's own historical baseline.

Continuous, timestamped build-time SBOM. Supply Chain Core records exactly which versions entered which environment and when, so the first question of every one of these incidents — did any of our builds run during the malicious window — is a query rather than a forensics project.

Lion for the credentials that are the real target. Every one of these campaigns was after credentials. Lion enforces just-in-time secret brokering, capability scoping, egress allowlists, and signed audit trails across build and agent environments, so a compromised dependency executing in your pipeline finds nothing durable to steal and cannot reach an exfiltration endpoint.

Eagle and Griffin for the response. Eagle scopes genuine exposure so rotation is proportionate rather than estate-wide. Griffin authors and tests the pinning, upgrade, and credential-migration PRs across every affected repository in parallel.

Ask your team how many people can publish to your organisation's package namespaces today. Then ask how many of them shipped anything this year.

Sources: Aikido — keyv compromise · Socket · CISA Alert — Nx Console and GitHub repositories · CrowdStrike 2026 Threat Hunting Report

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.