🎉 New here? Use code WELCOME10 for 10% off any plan at checkout
Free tool · Supply-chain training

Install Inspector

A teammate just asked you to add a package. You’re one npm install away from running it. Inspect it like a careful engineer, flag what’s suspicious, and decide — before the code runs. Get it wrong and you’ll watch the payload fire.

How it scores: block the malicious ones (and you’ll see what you dodged), install the safe ones (over-blocking costs you — friction is real), and flag the actual red flags. Not every package is poisoned; the skill is telling them apart.

Frequently asked questions

What is Install Inspector?

A free, interactive trainer that puts you in a developer’s seat the moment before running npm install. You inspect the package’s npm page, package.json, file list, version diff and provenance, flag the red flags, and decide whether to block or install — then see what the package would actually have done. It’s built to train the one habit that stops supply-chain attacks: inspecting install-time behaviour before trusting the registry.

How do attackers hide malware in an npm package?

The most common vector is a lifecycle script (preinstall / postinstall / install) that runs automatically on npm install, before you ever import or read the code — often an obfuscated blob that harvests environment variables, .npmrc tokens, cloud and SSH keys and exfiltrates them. Others use typosquatting (a name one edit from a popular package), dependency confusion (publishing your internal package name publicly with a huge version), remote second-stage payloads fetched at install, and — the subtle one — abusing a compromised maintainer’s legitimate CI so the malicious release is signed with valid provenance.

Does an install script in package.json mean the package is malware?

No. A lifecycle script is a yellow flag, not a red one. Native modules (sharp, libvips, better-sqlite3, Rust-based tools) legitimately use an install script to download a prebuilt binary from the project’s own release and checksum it. The skill is reading what the script does: fetch-and-verify-a-binary is fine; read-env-and-phone-home is not. The safest default is npm install --ignore-scripts with an allow-list for the few packages that genuinely need a build step.

Can a package signed with provenance still be malicious?

Yes — and this is the trap. Provenance attests where a build came from (which repo, which CI), not whether the code is benign. When a maintainer’s account or CI is compromised, their legitimate pipeline will sign genuinely malicious code with valid provenance. The @subql/common 5.8.3 incident in October 2026 shipped a credential stealer signed by real GitHub Actions. Treat "signed with provenance" as origin evidence, not a trust decision — and diff every version bump, including patches.

Is it free, and do I need an account?

It’s completely free and runs in your browser with no signup. PlayCISO is a simulation-first platform for security leaders — the War Room incident simulator, free readiness scorecards and more are all free to start.

Install Inspector — Spot the Malicious npm Package Before It Runs · PlayCISO