package.json Script Inspector
Paste a package.json and see exactly which scripts run automatically on install, and which dependencies aren't pinned
About this tool
The package.json Script Inspector reads a pasted package.json and surfaces two things that matter for supply-chain risk but are easy to miss scrolling through the raw file: which npm lifecycle scripts run automatically (without anyone explicitly asking for them), and which dependencies aren't pinned to an exact version. npm executes preinstall, install, and postinstall scripts automatically the moment npm install runs — with the full privileges of whoever's running it, before any test suite or code review happens. That combination is exactly why these specific scripts have been the recurring vector in real npm supply-chain worms, most recently the keyv/cacheable compromise in August 2026. This tool flags every lifecycle script present, explains what triggers it automatically versus what only runs when explicitly invoked, and calls out ones worth a closer look before you trust an install. It also flags dependencies pinned with a range (^, ~), a bare tag (*, latest), or installed directly from a git URL rather than the npm registry — each of which means a compromised maintainer account could ship a bad version that gets pulled in on your next install without you doing anything differently.
When to use it
- →Checking an unfamiliar package's install-time behavior before adding it to a project
- →Auditing your own project's package.json for lifecycle scripts you forgot were there
- →Reviewing dependency pinning practices before a security audit
- →Understanding exactly what changed in a suspicious dependency update
Tips
- ◆preinstall and postinstall are the two scripts worth the most scrutiny — they run automatically and are the most common vector for supply-chain malware in real incidents.
- ◆A dependency pinned with ^ or ~ isn't inherently dangerous, but it does mean the exact version installed can change between two people running npm install at different times — worth knowing before debugging a 'works on my machine' issue.
- ◆A dependency installed directly from a git URL skips the npm registry entirely, including whatever minimal review and provenance signals the registry provides — treat it with the same scrutiny as vendoring code directly.
Frequently asked questions
Does flagging a script mean it's actually malicious?
No — plenty of legitimate packages use preinstall or postinstall for real reasons, like compiling a native addon. The flag means 'this runs automatically, so it's worth knowing it's there and understanding why' — not an accusation. The point is visibility, since the same automatic-execution mechanism that's convenient for legitimate build steps is also what supply-chain malware relies on.
Why does an unpinned dependency matter if the package hasn't been compromised?
It's not about the package being compromised right now — it's about what happens if its maintainer's account ever is. A range-pinned (^1.2.0) or tag-pinned (latest) dependency will silently pull in whatever the compromised account publishes on your very next install, with no action from you. An exact-pinned dependency (1.2.0) requires someone to deliberately bump the version, which is at least one more chance to notice something's wrong.
Does this tool check my dependencies against a list of known-malicious packages?
No, deliberately — a hardcoded list of compromised packages goes stale within days of a new incident and would give false confidence once it's outdated. Instead, this tool focuses on structural risk factors (auto-running scripts, loose version pinning) that stay relevant regardless of which specific package is compromised this week.