/npm-supply-chain-check

name: npm-supply-chain-check
description: Detect known malicious npm package versions and install-time supply-chain indicators in repositories, lockfiles, and node_modules. Use when a user mentions an npm compromise, Shai-Hulud, the Keyv/cacheable incident, suspicious preinstall scripts, credential-stealing packages, or asks whether a JavaScript project was exposed to a package supply-chain attack. Do not use as a general CVE or license audit.

NPM Supply Chain Check

Run an evidence-bounded, read-only scan. Distinguish a dependency reference from proof that malicious code executed, and never read or print secret values.

Workflow

1. Fix the scan boundary

Resolve the exact repository or directory first. Default to the current repository only. Do not silently expand a repo scan to the user's home directory, all worktrees, global package caches, or CI systems.

2. Check intelligence freshness

Read `references/shai-hulud-2026-iocs.json` when investigating that incident. It is a dated minimum baseline, not a complete list of every affected community package. For an active incident, also check current primary sources such as the npm registry and maintainer/security advisories before declaring a version safe. Do not modify the bundled baseline during an ordinary scan.

3. Run the deterministic scanner

From this skill directory:

python3 scripts/scan_npm_supply_chain.py <target> --format text

Use JSON when another tool will consume the result:

python3 scripts/scan_npm_supply_chain.py <target> --format json

Add `--deep` only when source and built JavaScript files should also be searched for network and campaign strings. Deep mode still reports paths and indicators, not surrounding file contents.

Exit codes are machine-checkable:

• `0`: scan completed and found no indicators in the checked scope.
• `1`: one or more affected versions or suspicious indicators were found.
• `2`: the scan could not complete because its target or IOC data was invalid.

4. Classify the evidence

| Evidence | Meaning | |---|---| | Affected version in a manifest or lockfile | Exposure candidate; it does not prove installation or execution. | | Affected version under `node_modules` | Malicious package content may have been present locally. | | Known malicious SHA-256 | High-confidence local artifact match. | | IOC preinstall command or campaign/network string | Strong suspicious-content evidence; inspect provenance and timing. | | IOC filename with a different hash | Triage lead only; filenames such as `setup.mjs` can be legitimate. | | No findings | No known indicators in this scope and baseline; not proof of a clean machine. |

Correlate positive results with installation timestamps, CI run history, package manager logs, and the incident exposure window. Do not claim credential theft solely from a lockfile match.

Operating Contract

Direct actions: Run read-only local scans, inspect public advisories and registry metadata, and report exact package, version, path, indicator, scope, and confidence. For a positive result, recommend pausing installs and affected CI jobs, isolating suspect runners or machines, preserving logs, and rotating potentially exposed credentials from a known-clean device.

Escalate before: Ask for explicit authorization before any action that would:

• delete `node_modules`, caches, logs, or suspicious files;
• reinstall dependencies or regenerate lockfiles;
• revoke or rotate npm, GitHub, cloud, Kubernetes, Vault, payment, or chat tokens;
• upload local artifacts or secret-bearing logs to a third party.

Those actions change evidence or external state and require explicit user authorization. If asked to remediate, make a reversible evidence copy or record hashes first and name the exact target before changing it.

Evidence-backed pushback: When a user proposes only upgrading or reinstalling after strong local execution evidence, explain that package replacement does not revoke credentials that may already have been copied. Ground that warning in the scanner finding and the credential classes targeted by the current incident source.

Feedback loop: When a new affected package, version, hash, or stable IOC is confirmed by a credible source, update the JSON baseline and add a regression fixture before treating the detector as current.

Gotchas

• npm unpublishing prevents new downloads but does not remove local installs,

package-manager caches, container layers, or CI artifacts.

• Valid npm provenance proves how a package was published, not that the source

repository or maintainer account was uncompromised.

• Floating declarations such as `latest` do not prove which historical version

was installed. Prefer lockfiles, installed manifests, and install logs.

• Transitive packages may be absent from the root `package.json`; scan the

lockfile and `node_modules` when available.

• Binary `bun.lockb` files are reported as unsupported rather than silently

treated as clean. Use a text lockfile or Bun tooling to resolve exact versions.

• The bundled IOC list is intentionally source-attributed and dated. Extend it

through a reviewed data update, not an invented fallback.

Report

Return:

## NPM Supply-Chain Check
- scope: <absolute target>
- baseline: <incident and updated_at>
- result: clean | suspicious | affected | incomplete
- confidence: low | medium | high

## Findings
- <severity> <path> - <package/version or IOC and what it proves>

## Limits
- <missing lockfile, unsupported binary lock, stale baseline, or unchecked external scope>

## Next Actions
1. <smallest safe action>

The check is done only when a fresh scanner result is available, all warnings are surfaced, and conclusions stay within the scanned target and IOC baseline.

Resources

• `scripts/scan_npm_supply_chain.py`: read-only repository, lockfile,

`node_modules`, preinstall, filename, hash, and optional deep-string scanner.

• `references/s