Signed, Trusted, Compromised: The npm Supply Chain Attack That Fooled Every Security Gate

Every automated check passed. SLSA Build Level 3 attestations. Sigstore signatures. Valid GitHub Actions workflows. Green across the board. And yet, by May 2026, the Shai Hulud campaign had poisoned between 373 and 416 versions of some of the most widely-deployed npm packages in the ecosystem — including TanStack, the Mistral AI SDK, Bitwarden CLI, SAP tooling, and Guardrails AI.

This is not a story about a missing patch or a weak password. It is a story about a category error: the assumption that verification means safety. It does not. Verification means the build process was followed. It says nothing about whether the build process itself was clean.

For security leaders, the implications go well beyond npm. Your CI/CD pipeline, your package manager, your approved registries — they are now attack surface. If they are not in your threat model, you have a blind spot where an attacker is already operating.

What Happened

The Shai Hulud campaign began in September 2025. Attackers did not take the usual supply chain shortcut — typosquatting, dependency confusion, or publishing to an abandoned package name. They targeted legitimate, actively-maintained packages with large install bases. The goal was not to trick developers into installing a fake package. It was to compromise the real one.

To do that, they worked upstream. By compromising maintainer accounts or build infrastructure, they injected malicious code before the signing step occurred. The result: packages that carried all the verification markers a modern security gate is designed to check — SLSA attestations from GitHub Actions, Sigstore transparency log entries, correct provenance metadata — and were malicious underneath all of it.

By the time the campaign surfaced publicly in May 2026, poisoned versions had already been distributed across production environments worldwide. The packages are not obscure. TanStack (React Query and Router) alone is pulled hundreds of millions of times per month. Bitwarden CLI is used inside security teams. Guardrails AI sits in AI application stacks. The attack surface is the modern development environment itself.

Why "Signed" Is Not "Safe"

The security industry spent several years building the software supply chain verification stack. SLSA provides a framework of levels describing how trustworthy a build process is. Sigstore provides infrastructure for signing artifacts and recording them in a public transparency log. GitHub Actions became the de facto build environment, and major package registries began requiring attestations.

This was the right response to a real problem. The SolarWinds attack in 2020 demonstrated that a compromised build pipeline could distribute malware at scale through a trusted software update. The industry responded by creating a verification layer. Shai Hulud is a demonstration that the verification layer, on its own, is insufficient.

SLSA attestations verify the pipeline, not the input. A SLSA Build Level 3 attestation tells you that the artifact was built by a specific runner, from a specific source, using a specific workflow. It does not tell you that the source was unmodified or that the runner was uncompromised. If the attacker controls the input — the maintainer account, the source repository, the upstream dependency — the attestation faithfully records that a malicious build completed correctly.

Sigstore records transparency, not integrity. The Sigstore transparency log proves that a signature existed at a specific time. It is an audit trail, not a trust decision. A malicious artifact signed by a compromised key still appears in the transparency log as a valid entry. Revocation is slow, often manual, and frequently incomplete.

SCA tools are looking at the wrong layer. Software composition analysis works by comparing package hashes and versions against databases of known vulnerabilities. The Shai Hulud packages were not in those databases. They were newly published malicious versions of legitimate packages. There was no CVE to match against, no hash in the blocklist, no prior intelligence to correlate. SCA tools were architecturally blind to this attack.

The Real Attack Surface

Most organizations still define their attack surface around what is externally reachable: perimeter firewall, exposed services, web applications, VPN endpoints. That definition is about a decade out of date.

Your perimeter is your CI/CD pipeline. Code commits trigger automated builds. Builds pull dependencies from package registries. Packages execute inside your build environment, your test runners, your deployment pipelines. A malicious npm package does not need to find a vulnerability in your application. It is already running inside your infrastructure with the permissions of your build system.

Your perimeter is your package manager. npm, pip, Maven, NuGet — every package manager is a trust boundary that most organizations have never formally assessed. What registries are approved? Who can add new dependencies? What review process, if any, exists before a new package enters the dependency tree? In most organizations the honest answer is: developers add what they need, and no one checks.

Your perimeter is your developer's laptop. Maintainer account compromises — through phishing, credential theft, or infostealer malware — are how most upstream supply chain attacks begin. The developer laptop is the entry point. If your threat model does not include the personal devices and accounts of people who maintain packages your teams depend on, you are trusting a chain you cannot see.

What This Means for the Board

Supply chain risk has been in board conversations since SolarWinds. Most of those conversations have been abstract: vendor risk programs, third-party questionnaires, software bill of materials requirements. Shai Hulud makes the risk concrete.

The approved vendor list does not cover open-source dependencies. Your vendor risk program assesses companies — their SOC 2, their incident history, their security posture. It does not assess TanStack. It does not assess the individual maintainer who has commit access to the Mistral AI SDK. Open-source dependencies operate outside the vendor risk perimeter, and they are already inside your environment.

Compliance does not cover this. ISO 27001, SOC 2, and PCI-DSS all have supply chain clauses. None of them prescribe controls that would have detected or prevented the Shai Hulud attack. Attestation compliance — requiring SBOM, requiring signed packages — was the state of the art, and it failed. Boards should ask what controls exist beyond the compliance baseline.

The liability is not hypothetical. If a malicious npm package executes in your build pipeline, exfiltrates credentials, and enables a downstream breach, the question of who is responsible for the unreviewed dependency is not a technical question. It is a governance question. Boards that have not asked where open-source risk sits in the risk register are behind.

Five Actions This Quarter

These are concrete, ordered by leverage, and achievable inside a quarter for any organization with an existing security engineering capability.

1. Audit your dependency inventory. Before you can assess risk, you need to know what you have. Run a full dependency tree across your codebases. Count the packages. Count the ones that have never had a human review the source. That number is your unmonitored attack surface.

2. Enforce dependency pinning and lock file review. Pinning dependencies to exact versions and requiring lock file review in pull requests is the most immediate control you can add. It does not prevent a maintainer compromise, but it prevents silent version upgrades that could silently pull in a poisoned release.

3. Add runtime behavioral monitoring to your build pipeline. Verification at install time is insufficient, as Shai Hulud demonstrated. Monitoring what packages actually do at runtime — network connections, file system writes, process spawning — catches malicious behavior that passed every pre-deployment check.

4. Treat CI/CD as regulated infrastructure. Your build pipeline should have the same access controls, audit logging, and anomaly monitoring as your production environment. Most organizations apply far less scrutiny to their build systems than to their customer-facing applications, despite the fact that a build system compromise reaches everything downstream.

5. Map your open-source exposure to your risk register. Identify which external packages have access to your secrets, your credentials, your build artifacts. Treat high-privilege dependencies — ones that run during builds, handle authentication, or interface with production systems — as third-party vendors that require periodic review, not a one-time install.

The Deeper Lesson

Every time the security industry builds a trust framework, attackers study it for the gap between what it verifies and what it assumes. SLSA and Sigstore are good engineering. They solve a real problem. Shai Hulud found the boundary of what they guarantee and operated precisely there.

That pattern repeats. Firewalls assumed applications were trusted — so attackers moved to the application layer. EDR assumed endpoints were the attack surface — so attackers moved to identity and SaaS. Supply chain verification assumes the build process is the trust boundary — so attackers moved upstream of it.

The defensive response is not to abandon verification. It is to stop treating any single control as a trust proxy. Signed does not mean safe. Attested does not mean uncompromised. Approved registry does not mean reviewed. Every verification marker tells you something specific and limited. The CISO's job is to know what each control actually guarantees — and to instrument the gaps.

Frequently Asked Questions

What is the Shai Hulud attack?

A supply chain campaign that began in September 2025 and by May 2026 had poisoned 373–416 versions of major npm packages including TanStack, Mistral AI SDK, Bitwarden CLI, SAP tooling, and Guardrails AI. All malicious versions carried valid SLSA attestations and Sigstore signatures, causing every automated security check to pass.

How did attackers sign malicious packages?

They compromised build infrastructure or maintainer accounts before the signing step. Signing happened after the malicious code was already present, so attestations accurately reflected the (compromised) build process. SLSA verifies the pipeline was followed — not that the pipeline was uncompromised.

Will SCA tools catch this?

No. SCA tools compare against known vulnerability databases. Newly published malicious package versions have no prior CVEs to match against. SCA remains necessary but cannot detect supply chain attacks that operate before vulnerability databases are updated.

What is the most important control to add?

Runtime behavioral monitoring inside the build pipeline. If a dependency executes malicious behavior — unexpected network connections, credential access, file exfiltration — runtime detection catches it regardless of whether it passed pre-deployment verification.

How does this affect compliance posture?

Existing compliance frameworks do not prescribe controls that would have prevented this attack. SBOM requirements and package signing mandates were the state of the art — and they failed. Boards should ask what controls exist beyond the compliance baseline for open-source dependency risk.