Coding agents
Gate package installs before an agent runs them — Codex, Claude Code, Cursor, Windsurf.
Coding-agent guide →pkgxray
Analyze packages before you install them.
Zero-dependency · runs locally · static scans never execute package code
npm is the primary target for open-source malware.
Agents install packages and connect to MCP servers at machine speed. The registry they pull from is under industrial-scale attack.
CVE scanners find known bugs. pkgxray asks what the code does — before a single line runs on your machine.
Each figure links to its supporting report. Sources include Sonatype’s 2026 State of the Software Supply Chain, its open-source malware chapter and Q4 2025 OSS Malware Index, Palo Alto Networks’ incident analysis, and NimbleBrain’s MCP registry analysis.
Calibration · scanned 2026-07-21
So how often does it call it right?
We ran the scanner over 5,000 published packages — code only, no execution — read every block by hand, and measured recall against a committed, reconstructed known-malware corpus.
5,000
packages scanned
top-1,000 list + 4,000 deeper sweep, one static pass
0
false blocks, top 1,000
14 found and fixed in the next 4,000
20 of 21
corpus samples blocked
0 passed as safe
Watch a verdict form
Pick a package. This demo replays real fixtures — it does not download or execute anything in your browser.
pkgxray guard
Three verdicts. Stable exit codes.
Click a verdict to see what it means for install, CI, and agents.
No high- or medium-risk indicators. Default policy promotes out of quarantine. Install.
What it catches
Deterministic heuristics — no LLM in the verdict path, so injected text can't steer them.
| Threat | Coverage | How pkgxray sees it |
|---|---|---|
| Credential theft | ✅ | reads of .ssh / .aws / .npmrc / .env / keychains / wallets, incl. split-fragment paths (".s"+"sh") |
| Prompt injection | ✅ | tiered detection in docs, comments, metadata; deterministic verdict path can't be steered |
| Unicode smuggling | ✅ | invisible tag-block characters + Trojan Source bidi / zero-width |
| Base64 payloads | ✅ | encoded envelopes in docs/comments; blobs decoded into computed-arg eval / new Function / child_process |
| Exfiltration & loaders | ✅ | cross-file correlation: stage-2 loaders, curl | sh, process.env harvesting near a network sink |
| Persistence | ✅ | writes to shell rc files, cron, launch agents |
| Obfuscation | ✅ | packed blob + computed-arg execution; minification alone is deliberately not flagged |
| Known CVEs | ✅ | OSV batch pre-check before download; never mutable by config |
| Trojaned updates / takeover | ✅ | recheck verdict-drift + version-drift monitoring |
| Artifact divergence | ✅ | published npm tarball diffed against the tagged GitHub source |
| MCP capability abuse | ✅ | capability-surface mismatch in the manifest audit (a get_weather that also takes a command) |
| Runtime tool drift | ✅ | mcp-proxy re-audits on tools/list_changed; pinned-manifest drift is denied |
| Sequence-level tool-call chains | ◑ | mcp-proxy gates each call and scans results; no cross-call flow analysis |
| Dependency confusion / typosquats | ◑ | callback beacons, repo- and provenance-mismatch signals; no name-similarity heuristic |
✅ detected · ◑ partial / indirect. Known blind spot: a package that downloads its real payload after install can ship a clean tree — pair pkgxray with runtime sandboxing when that risk matters. Full threat model →
One engine. Every surface.
CLI, MCP, install hook, and CI all share the same policy and the same evidence rules.
- guard Quarantine a package, audit bytes, promote only if allowed
- mcp Vet a server before connect — most public MCP servers ship with static keys and little verification
-
hookshot
Intercept agent
npm installwith cited deny - recheck Catch trojaned updates against a stored baseline
Where pkgxray fits
One engine, wherever packages enter your stack. Each path has a setup guide in the repo.
MCP
Audit a server's package and declared capabilities before
connecting; gate live traffic with mcp-proxy.
CI/CD
Fail builds when a dependency crosses policy; scan the whole
lockfile and re-vet on a schedule with recheck.
Developers
Inspect an npm package before installation — one command, a cited verdict, no account.
Try it →How pkgxray compares
Run it alongside npm audit and OSV-Scanner, not
instead of them — they answer "known CVE?". The comparison
that matters is against tools in the same lane: behavioral
supply-chain vetting.
| Capability | Socket.dev | OpenSSF Pkg Analysis | Cisco MCP Scanner | pkgxray |
|---|---|---|---|---|
| Fully local, zero-dependency, no account or cloud upload | — | ◑ | ◑ | ✅ |
| Static behavior analysis of package code | ✅ | ✅ | ✅ | ✅ |
| Sandboxed execution (dynamic analysis) | — | ✅ | ◑ | ◑ opt-in canary |
| npm ↔ GitHub artifact divergence | unknown | — | — | ✅ |
| Deterministic verdict path — no LLM an injection can steer | — | ✅ | ◑ | ✅ |
| Pre-install gate with a quarantined copy to review | ◑ | — | — | ✅ |
| MCP server vetting before connect | — | — | ✅ | ✅ |
| Per-call runtime gating of live MCP traffic | — | — | — | ✅ mcp-proxy |
| Verdict-drift monitoring vs. a stored baseline | ✅ cloud | — | — | ✅ local recheck |
Last reviewed against public documentation: 2026-07-21 (re-reviewed every 60–90 days). A — means no equivalent capability was found in the public documentation reviewed on that date — not that it was tested and found absent; unknown means not publicly documented either way. Full per-tool notes: comparison.md →