Pkgxray – 检查安装内容,而非执行内容
Pkgxray – inspect what gets installed, not what executes

原始链接: https://github.com/adamsjack711-ux/pkgxray

**pkgxray** 是一款本地化、零依赖的安全工具,旨在保护开发者和人工智能代理免受恶意 npm 包及模型上下文协议 (MCP) 服务器的侵害。通过对沙盒隔离环境下的软件包副本进行静态分析,它能在代码执行或安装前给出确定性的结论——**安全 (SAFE)、审查 (REVIEW) 或 拦截 (BLOCK)**。 **主要功能:** * **零执行分析:** 在不运行生命周期脚本或构建步骤的情况下检查代码、元数据和制品来源,从而防止安装前的恶意软件攻击。 * **全面的威胁覆盖:** 检测凭据窃取、提示词注入、混淆加载器、Unicode 欺骗以及制品差异(npm 压缩包与 GitHub 源码不匹配)。 * **MCP 安全性:** 在建立连接前审核工具清单,并使用 `mcp-proxy` 拦截实时流量,剥离未经授权的工具调用。 * **工作流集成:** 通过安装钩子、CI/CD 流水线和 MCP 代理,与 AI 编码助手(如 Cursor、Claude Code)集成。 * **透明的证据:** 与黑盒工具不同,pkgxray 为每一次“拦截”或“审查”结论提供引用证据,确保可追溯性。 pkgxray 专为高速、本地优先的安全性而设计,为现代自动化开发环境提供了严格的“默认拒绝”式防御机制。

抱歉。
相关文章

原文

pkgxray — pre-install security for npm packages, MCP servers, and AI agents.

Use local, zero-dependency package static analysis to inspect npm packages and Model Context Protocol (MCP) servers before installation or connection. pkgxray reports cited SAFE, REVIEW, or BLOCK evidence without executing package code during normal scans.

npm version tests calibration benchmark license: MIT

Static analysis · Supply-chain intelligence · Prompt-injection detection · MCP security · SAFE / REVIEW / BLOCK

pkgxray guard clearing express@4.21.0 with a SAFE A+ verdict, then blocking a trojaned sample with a BLOCK F verdict and a HIGH credential-access finding citing the wallet-read and exfiltration code

Real runs: guard clears [email protected], then blocks a sample modeled on the 2024 @solana/web3.js compromise. ▶ 60-second walkthrough

1. Scan a known-safe package without installing pkgxray

This downloads pkgxray through npm's temporary npx cache, stages the target tarball in quarantine, and performs the static and supply-chain checks. It does not globally install pkgxray, run npm install, execute lifecycle scripts, or execute package code.

Decision: **SAFE**
Grade: **A+** (99/100)

No high- or medium-risk indicators were found in the provided evidence.

Notes:
- **INFO npm-vs-github-clean** — npm tarball matches the linked GitHub repo
  at the published version. (15/16 files match GitHub @4.21.0)
…

Real output, abridged. A BLOCK verdict instead lists every finding with the file and evidence that produced it.

Point it at a package, get a verdict with cited evidence — before a single line of that package runs. guard stages the package in a sandboxed quarantine, audits the staged copy, and only promotes it when policy allows. It never runs npm install, lifecycle scripts, build steps, or package code.

Verdict Exit Meaning
SAFE 0 No high- or medium-risk indicators were found; default policy permits promotion.
REVIEW 3 Evidence is incomplete or a privileged capability needs human review.
BLOCK 2 High-severity cited evidence requires rejection or deep investigation.

SAFE is not a proof that a package is harmless; static analysis cannot see a payload downloaded only at runtime. See the threat model.

3. See a BLOCK on the supplied inert fixture

From a repository checkout:

npx --yes [email protected] --file examples/onboarding-malicious.json --format markdown

The fixture contains inert source text that models a split-string SSH-key read and network exfiltration. It is never executed. The command returns BLOCK (exit 2) and cites the matching file and evidence.

4. Add it to your workflow

AI coding assistants install packages and connect to MCP servers at machine speed, often without a human ever reading the code. Sonatype reported 454,648 newly identified malicious open-source packages across monitored ecosystems in 2025. Its Q4 report counted 394,877 in that quarter and said 99.8% of Q4 malware originated from npm (annual figure; Q4 scope). Traditional antivirus inspects what executes; pkgxray inspects what gets installed.

npm audit and OSV-Scanner answer an essential question — does this package have a known CVE? — and pkgxray asks it too (via OSV, before anything downloads). But a freshly trojaned package has no CVE yet, so pkgxray also analyzes trust: what the code actually does, whether the published npm artifact matches the tagged GitHub source, whether the provenance attestation is consistent with the claimed repository, and whether the docs carry a prompt-injection payload aimed at the agent reading them.

It is intentionally conservative: verdicts come from deterministic heuristics (no LLM in the verdict path, so injected text can't steer them), only citable evidence is reported, and the zero-heuristic-false-block calibration on the top-1000 most-downloaded packages is regression-gated in CI. That claim is scoped to the most-installed set — it is not a claim of zero false blocks on every package; the newer MCP/agent-tooling ecosystem is over-blocked and being reconciled per-case (details).

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, EtherHiding
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 / maintainer 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 — honest limits
Dependency confusion / typosquats callback beacons, repo-mismatch and provenance-mismatch signals; no name-similarity heuristic

✅ detected · ◑ partial / indirect

Known blind spot: pkgxray reasons about bytes in the tarball. A package that downloads its real payload after install can ship a clean tree — pkgxray flags the capability when its shape is unambiguous, but pair it with runtime sandboxing when that risk matters. Full analysis: docs/threat-model.md.

  • Continuous monitoringpkgxray recheck diffs installed deps against a stored verdict baseline and pre-vets newer versions
  • MCP vettingpkgxray mcp audits a server's tool manifest before you connect; --pin / --recheck catch the rug-pull; pkgxray-mcp gives any agent the audit tools directly
  • Runtime gatepkgxray mcp-proxy wraps a live MCP server on the wire: denied tools stripped, ~0.05 µs per-call verdict, injection scan of tool results
  • Install gate — a hookshot hook runs guard on every package an agent tries to install, across Claude Code, Cursor, Windsurf, Factory Droid, and Codex (examples/hookshot/)
  • Policy engine — one .pkgxray.json read by every surface; tighten freely, every loosening is printed; CVEs can never be allowed away; fail closed
  • Opt-in behavioral canarypkgxray canary runs lifecycle scripts in an OS sandbox with decoy credentials; it can confirm malice, never clear a package
Verdict Meaning You should
🟢 SAFE No high- or medium-risk indicators. Install. Only safe promotes out of quarantine by default.
🟡 REVIEW Incomplete evidence, or a privileged capability that needs a human. Inspect the quarantined copy before promoting.
🔴 BLOCK High-severity, cited evidence. Do not install. Every finding names the file and evidence.

Exit codes are stable and CI-friendly: 0 safe/allow · 2 block · 3 review. The full signal-to-severity mapping is in the severity policy.

Vet an npm package before installing

pkgxray guard npm:[email protected] [--format json]
pkgxray guard ./ext --promote-to ./approved/ext   # local dir, promote if policy allows

Vet an MCP server before connecting — full guide: docs/mcp.md

pkgxray mcp --package npm:[email protected] npx some-mcp-server
pkgxray mcp --recheck npx some-mcp-server   # catch the rug-pull

Enforce in CI/CD

pkgxray audit package-lock.json [--deep]    # also: yarn.lock, pnpm-lock.yaml, package.json
npx pkgxray recheck package-lock.json       # scheduled: exits non-zero only on a regression

A ready-made GitHub Actions integration and the self-hostable cache server (PKGXRAY_CACHE_URL) are documented in the reference.

Guard AI coding agents

pkgxray is published on the MCP Registry as io.github.adamsjack711-ux/pkgxray. Add it to any MCP client — locally installed (pkgxray-mcp) or zero-install via npx:

{
  "mcpServers": {
    "pkgxray": {
      "command": "npx",
      "args": ["--yes", "--package", "[email protected]", "pkgxray-mcp"],
      "env": { "PKGXRAY_MCP_ALLOWED_ROOTS": "/absolute/path/to/project" }
    }
  }
}

The MCP guide explains the operator-owned filesystem boundary. Product-specific setup is in the coding-agent integration guide. Gate installs with the Hookshot integration and wrap MCP servers with pkgxray mcp-proxy.

One optional .pkgxray.json, read by every surface. Zero config means maximum strictness.

Precedence, mute / mcp blocks, and enforced invariants: docs/configuration.md · .pkgxray.example.json

The 60-second walkthrough — the SAFE run, the blocked trojan with its exit code, then a lockfile audit:

pkgxray-demo.mp4

All captures are real runs — reproduction steps in docs/screenshots/, which also shows the MCP proxy, hookshot install gate, and browser extension in action.

npm audit and OSV-Scanner match dependencies against known CVEs — a different question, answered well. pkgxray is designed to run alongside them, not replace them (it queries OSV itself, before anything downloads). The comparison that matters is against tools in the same lane — behavioral supply-chain vetting:

Capability Socket.dev OpenSSF Package Analysis Cisco MCP Scanner pkgxray
Fully local, zero-dependency, no account or cloud upload — ¹ ◑ ² ◑ ³
Static behavior analysis of package code
Sandboxed execution (dynamic analysis) ✅ ⁴ ◑ (optional Docker) ◑ (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-side) ✅ (local recheck)

Comparison made 2026-07-21 against each tool's public documentation; unknown means not publicly documented — not verified either way.
¹ Socket's analysis runs in its cloud; Socket Firewall needs no account but consults Socket's hosted intelligence on every install. ² Open source and self-hostable, but built as a registry-scale analysis pipeline (Docker/gVisor), not an install-time developer gate. ³ The YARA analyzer runs locally; the LLM-as-judge and Cisco AI Defense analyzers require API keys. ⁴ Both detonate packages in an OS sandbox. pkgxray's opt-in canary runs two phases — install-time lifecycle scripts and the import of the package entry point — with decoy credentials, so the malicious-on-first-require (flatmap-stream) shape that is pkgxray's stated blind spot is triggered and observed. Egress is now kernel-confined on both platforms: sandbox-exec on macOS and, on Linux with bubblewrap + iproute2, a private network namespace (bwrap+netns) where a raw-socket dial that bypasses the proxy is refused by the kernel (ENETUNREACH) while proxied egress is still captured. That tier engages only after a runtime self-test proves it in the environment (verify with node scripts/verify-netns-confinement.js); absent the tooling it falls back to observe-only and says so. Still ◑ — not for a confinement gap, but by design: canary is opt-in and confirm-only (it proves malice, never clears a package) and detonates without the package's dependencies installed, whereas OpenSSF Package Analysis runs registry-scale and default-on. Run them as complements — pkgxray before install, full dynamic analysis where that risk matters. ⁵ Socket's LLM-based code inspection is a headline feature (“AI-detected potential malware”, human-confirmed); Cisco's YARA-only mode is deterministic, its LLM analyzer is not. ⁶ Socket Firewall blocks risky packages at install time; it does not stage a quarantined copy for human review. ⁷ Socket's MCP offering exposes its package-scoring API to agents; it does not vet arbitrary MCP servers at connect time. ⁸ Cisco MCP Scanner is analysis-only per its docs — it does not proxy or gate live MCP traffic.

pkgxray architecture: inputs flow through the acquisition, quarantine, static-analysis and policy engines to a SAFE / REVIEW / BLOCK verdict

Acquisition (OSV pre-check → fetch) → sandboxed quarantine → static analysis → policy → verdict. The same engine backs every surface: CLI, MCP server, runtime proxy, install hook, browser extension, and CI cache server. Principles: never execute untrusted code · citable evidence only · minimize false positives · fail closed · zero runtime dependencies.

Details: docs/architecture.md · docs/design.md

  • Local static analysis: ~25 ms — a full guard of express is ~1.3–1.5 s cold-cache, almost all network round-trips (Apple M1, Node 26)
  • Known-vulnerable packages block at the OSV pre-check, before download
  • Calibration (precision, recall, the 0-heuristic-false-block gate on the top-1000 most-downloaded — scope) is measured by a committed benchmark corpus that fails CI when it regresses

Full numbers: docs/reference.md#performance · methodology: docs/benchmark.md

Start at the documentation index. Longer-term plans: project status, adoption playbook, and GitHub issues.

npm test                 # zero-dep node --test suite
npm run benchmark        # calibration corpus: precision/recall + 0-false-block gate
npm run build:browser    # build the MV3 browser extension

Contributions are welcome; read CONTRIBUTING.md and the Code of Conduct before opening a pull request.

Releases are published to npm with provenance (SLSA attestation), gated on the test suite, the calibration benchmark, and pkgxray's own supply-chain guard. To report a vulnerability in pkgxray itself, see SECURITY.md.

MIT

联系我们 contact @ memedata.com