Detecting Shai-Hulud npm supply-chain worms offline

You can catch most opportunistic npm supply-chain worms without a network or account by statically parsing every package's install script, checking package names against a bundled corpus of known-malicious entries, and flagging any trusted package whose lifecycle script suddenly drifts from its known-good fingerprint. Static analysis will not run or sandbox the code, so treat it as defense-in-depth, not a guarantee.

The threat

Most supply-chain compromises do their damage in a package's lifecycle scripts (preinstall, install, postinstall) — code that runs automatically the moment you npm install, before you import anything. The Shai-Hulud class of worm is the hard case: it doesn't ship as an obviously-bad new package, it injects itself into the install script of a package you already trust, so a blocklist of bad names never sees it.

What offline static auditing can catch

• Dangerous script behavior — real JavaScript AST parsing (via acorn, the parser used by webpack, rollup, and eslint) finds eval/new Function, dynamic require()/import(), network builtins, child_process use, and process.env reads in install scripts.
• Anti-evasion — folding simple string concatenation and decoding one layer of base64 defeats tricks like require('ht' + 'tps') and base64-encoded secret paths.
• Known-malicious names — matching against an offline corpus (~23,000 names from the GitHub Advisory Database) catches a first-install of a confirmed-bad package even with no baseline.
• Fingerprint drift — fingerprinting the lifecycle scripts of widely-used native packages (esbuild, sharp, prisma, bcrypt, and similar) means legitimate postinstall work doesn't drown the report, and any unexpected change to a trusted script is flagged as critical. This is the Shai-Hulud tell.
• Baseline diff — snapshotting inventory and script hashes surfaces newly-added packages, version changes, and packages that gained a lifecycle script on upgrade.

What it does not do

It is not a sandbox and does not block npm install — pair it with npm's ignore-scripts or an allow-list tool to actually prevent execution. It is not a CVE scanner — use osv-scanner or npm audit for known vulnerable versions. And it cannot deobfuscate arbitrary JavaScript. Its value is being small, auditable, deterministic, and runnable anywhere.