How Efeeo Release Assurance Helps You Respond to the Next Shai-Hulud

Exposure readiness for supply-chain worms that move through packages, credentials, and CI/CD.

Audience	CISO, VP Security, AppSec, PSIRT, and engineering leadership
Use case	Supply-chain exposure readiness for npm-style credential-stealing worms
Document type	Customer brief

Executive Summary

When the next Shai-Hulud-style advisory drops, Efeeo answers three questions: which assessed releases contain the compromised package or version, where those releases deployed, and where the evidence is incomplete.

In the September 2025 Shai-Hulud campaign, a malicious npm package didn't just compromise code at install time, it harvested developer and cloud credentials, then used stolen publishing access to spread itself into additional packages. Most incident responders learned the same hard lesson: containment was slow and sometimes inconclusive, because organizations had no reliable visibility into which npm packages (and which versions) were actually included in their own software releases. The conclusion was an uncomfortable realization of a structural gap: most incident response programs simply weren't built for software supply chain compromise.

Efeeo Release Assurance is built for that structural gap. When an incident hits, your product security incident response team doesn't have to reconstruct history from build logs and tribal knowledge. They query our system directly and get answers in minutes, not weeks.

What We Answer During an Incident

Incident question	Release Assurance answer
Did we ship the poisoned package or version?	Query sealed SBOM evidence across release history, not only the current repository state.
Where did it deploy?	Return the releases and deployed environments bound to the affected component.
Can we trust the release history?	Independently verify the evidence itself — offline, against a signing key you hold — so the record can't have been altered by the same attacker you're investigating.
Where can we not yet say?	Surface missing scanner, review, provenance, or deployment evidence as a named gap.

How It Works

Each assessed release runs through "ra-run". The runner assembles read-only, metadata-only evidence and binds it to the release identity in one graph. The GitHub connector can source commits, pull requests, reviews, approvals, principals, dependency inventory, code-scanning findings, secret-scanning alerts, and build attestations. Deployment logs, repository-governance settings, file-change detail, and dependency-automation detail can be ingested as supplied evidence files where direct collection is not yet wired.

Verdicts are pure functions of the evidence. No model sits in the verdict path, so the same evidence yields the same result. The fleet is an append-only ledger of sealed records; queries run across release history, not just the latest build. An optional natural-language aid, ra-ask, can help explore the fleet graph, but it is read-only and never on the record path.

Command Examples

Question	Example command
Locate affected releases	`ra-fleet --fleet ./fleet where-is <package[@version]>`
Find review gaps	`ra-fleet --fleet ./fleet which-releases --with unreviewed-ai-changes`
Find coverage gaps	`ra-fleet --fleet ./fleet which-releases --missing scanner`
Verify the record	`ra-verify --fleet ./fleet`

For scoped packages, use the package input format supported in your deployed CLI version.

Technical Limits

Exposure and coverage are separate. "where-is" tells you where a package is present; which-releases --missing tells you where evidence is incomplete. A human analyst reads both.
Exposure is not reachability. Release Assurance can show that a compromised component shipped and deployed. It does not prove whether a vulnerable code path was invoked.
Review history is not npm publish history. Self-approval and unreviewed-change signals are GitHub/release-history controls. A stolen npm-token publish can bypass that history unless registry publish logs are supplied or integrated.
The key proves tamper-evidence, not endorsement. The signed record shows that the pack or fleet has not changed since sealing. Independent assurance depends on the customer holding or pinning the engagement public key.

Baseline Engagement

In roughly 30 days, Efeeo backfills a scoped release family, builds a live signed fleet, and replays a public supply-chain event end to end. The exercise includes an intentionally hard case where evidence is genuinely missing and the fleet returns cannot yet say instead of inventing confidence.

Scope one release family and one incident question.
Backfill release evidence and seal the historical fleet.
Replay a Shai-Hulud-style compromised-package advisory.
Validate the exposure answer, the coverage gaps, and the offline verification path.
Use the resulting fleet as the foundation for continuous response and compliance evidence.

Customer Takeaway

When the next supply-chain worm lands, your PSIRT queries a signed operational record and gets three things: affected releases in minutes, named gaps instead of false clears, and a tamper-evident exposure record your leadership can stand behind.

Appendix

We pointed Release Assurance at a demo environment release history — four releases — and asked it the five questions a security leader has to answer when a supply-chain zero-day lands.

The question a leader must answer under pressure	What the run returned	What it means for you
Which of our releases contain the affected component, and where are they running?	Every release that shipped the component, each with its deployment location (in seconds)	The multi-day "are we affected" scramble becomes a seconds-long lookup. You can stand behind a customer advisory the same day, not the same week.
Did code reach production without a human reviewing it?	All four releases carried AI-authored changes with no human approval on record	You can see — and prove — a governance gap that is invisible in most dev teams today, and get ahead of it before an examiner finds it for you.
Did anyone approve their own change?	None — verified, not assumed	A specific insider-risk and honest-mistake check, answered with evidence rather than a shrug.
Which releases can we not yet vouch for?	Three of the four had no security-scan evidence on file	The tool tells you what you don't know instead of issuing a false all-clear — so you never tell a customer "we're clean" when you actually can't see.
Can this record be trusted, or quietly altered?	The record verified as sealed and tamper-evident	The evidence you hand to an auditor, a customer, or your board cannot be changed after the fact — by anyone, including us.

Want this run against your own release history?

Get in touch