[DEEP RESEARCH] The registry did not see the breach. The runner did.

The judgment: package registries are the first to receive a malicious release, but they are not reliably the first to recognize the incident. In the Axios and Mini Shai-Hulud cases, release analysis surfaced suspicious artifacts early; the CI runner held the highest-confidence evidence of what the package actually did. The tension is timing: runtime truth arrives only after execution has begun, often beside credentials and release authority. The payoff is a defensible operating model—gate risky versions before execution, instrument the install job as an incident sensor, and trace every exposed build to its artifacts, deployments, and reachable secrets.

TL;DR

• The registry sees publication. It has the earliest broad view of package versions, publishers, manifests, tags, archives, and provenance—but unusual is not automatically malicious.
• Package analysis can recognize intent before installation. Dependency-graph changes, new lifecycle scripts, archive growth, obfuscation, Git dependencies, and a changed publishing path can justify quarantine.
• The runner sees behavior. Process ancestry, file writes, secret access, identity-token requests, workflow changes, and egress can turn suspicion into an organization-specific incident.
• A valid attestation is not a clean bill of health. Mini Shai-Hulud reportedly used a compromised release pipeline to produce malicious packages with valid SLSA provenance.[5]
• The principal decision is ownership. AppSec and platform engineering own admission; platform security and detection engineering own runtime controls; identity and cloud security own rotation; engineering productivity and IR own lineage and impact.
• One clean win: identify every CI job that installs dependencies while holding signing, publishing, deployment, source-control, or broad cloud authority. Remove that authority or move installation into a separate job.

The registry is the earliest witness. The runner is the first witness inside your blast radius. Confusing those roles leaves a gap attackers can use.

Four clocks, not one “first detector”

The familiar question—who detected the breach first?—compresses four different clocks into one:

In the Axios incident, npm necessarily processed the malicious publications first. Public reporting does not establish that registry controls independently recognized the compromise before outside analysis, community reports, and maintainer escalation. The Axios postmortem describes community reporting, deleted issues under the compromised account, maintainer action, and subsequent registry removal.[1] Elastic reported automated supply-chain monitoring that identified suspicious release behavior, including a changed publisher and publishing method, missing expected provenance, and a newly inserted dependency.[3]

That distinction matters. A publication event is evidence that something happened. A runner process tree showing npm leading to a lifecycle script, a downloader, an unapproved destination, and secret access is evidence of what happened to you.

Runtime is therefore not “earlier” than the registry. It is more decisive at a different point in the sequence.

What the two incidents actually teach

Axios: the source tree was not the useful inspection point

The malicious Axios releases added plain-crypto-js@4.2.1 as a dependency. Its postinstall hook launched node setup.js, retrieved a platform-specific second stage, and attempted to clean up the loader and restore a benign-looking manifest.[1][2][3]

That sequence creates three distinct defensive opportunities:

1. Before installation: flag the dependency-graph change, lifecycle hook, changed publisher or publishing path, and lost expected provenance.
2. During installation: correlate the package manager with child interpreters, downloader activity, temporary-file execution, and egress to an unapproved destination.
3. After warning: use lockfiles, build records, endpoint and network telemetry, artifact lineage, and credential reachability to determine impact.

A source review focused on Axios itself could miss the malicious behavior because the operative change sat in a transitive release dependency. A later filesystem inspection could also understate exposure because the loader attempted to remove evidence. The package looked cleaner after doing the dirty work. That is not subtle tradecraft; it is a bet that post-incident evidence will be incomplete.

Mini Shai-Hulud: provenance described the compromised path

The later TanStack-related Mini Shai-Hulud activity raised the stakes. StepSecurity reported a cache-poisoning chain, theft of GitHub Actions OpenID Connect material from runner memory, malicious publication through authorized release infrastructure, and valid SLSA Build Level 3 provenance on the resulting artifacts.[5]

The useful lesson is not that provenance failed. Provenance still records which identity and pipeline produced an artifact, supports comparison with expected release paths, and gives responders an audit trail. The lesson is narrower: provenance answers “which authorized path produced this?” It does not answer “was that path uncompromised?”

Package analysis reportedly saw archive growth, an obfuscated root-level payload, an unexpected Git-linked optional dependency, and rapid releases. Runtime monitoring then exposed the execution sequence: npm to Node.js and shell activity, Bun egress, credential-access tooling, Python reading runner memory, and GitHub API use.[5]

The attestation was valid. So was the incident.

Evidence state

Observed: Public postmortems and vendor reporting document malicious npm releases, lifecycle-driven execution in Axios, publication anomalies, and external and community escalation.[1][3] Separate reporting on Mini Shai-Hulud documents runtime behaviors associated with credential access and propagation.[5]

Assessed: The strongest enterprise design is a relay, not a contest. Registry and package analysis should buy time before installation; CI telemetry should confirm and stop dangerous behavior; downstream lineage and identity telemetry should establish impact. We assess this with high confidence because each layer answers a different necessary question and each has a known blind spot.

Unknown: Public timestamps do not resolve one universally “first” detector for every phase of Axios. Registry operators may also hold nonpublic detections or sensitive telemetry. It remains unclear how consistently ordinary organizations can capture runner memory access, complete process lineage, and artifact provenance without unacceptable cost or false positives.

What would change our mind: Evidence that registry controls consistently detect and contain major malicious releases before downstream installation would reduce the need to treat CI as an early-warning layer. Evidence that well-scoped runtime correlations remain too noisy to operate would weaken the case for behavioral prevention, though not the need for forensic retention.

Ask your team today:

If a malicious transitive dependency executed in your most privileged build today, who could name the reachable secrets, stop the next install, and identify every descendant artifact before the next release window?

Public reporting gives you the incident timeline and indicators. The paid decision value below is the operating model: who owns each control, what gets admitted, what the runner must record and stop, and how to prove impact within hours rather than assemble it from tickets after the trail has cooled.

We also include the technical deep dive.

Build a relay with named owners

No one needs another control framework where every box is assigned to “Security.” Name accountable owners and the outcome each must produce.