RepoXray本地扫描依赖与MCP配置风险

运行 npm install、把仓库交给 AI 编程代理之前，先检查依赖和凭证暴露面，这是 RepoXray 想补上的一步。它把 AI 编造包名带来的供应链风险、MCP 配置中的危险执行方式，以及代理可能读到的 .env 放到一起扫描。

工具的卖点是浏览器扫描零上传、CLI 体积小，还能生成防护文件。不过原文是一则作者自荐，没有误报率、检出率或对照实验。值得看的是它选中了哪些风险，以及这些检查能覆盖到哪里。

AI 编出来的包名，为什么也要查供应链

作者关注的是 slopsquatting：LLM 可能生成看起来合理、实际不存在的包名。一个包今天在 npm 返回 404，攻击者明天就可能注册它。后续用户再照着 AI 的建议安装，包名已经存在，来源却可能有问题。

包能安装成功，不等于它就是你原本想装的包。

RepoXray 为此组合了几类检查：实时查询注册表中的包是否存在，标记包龄 <21 days 的依赖，通过 OSV.dev 查询漏洞公告，并检查高风险的 postinstall shell 和网络钩子。查询漏洞时，它会解析 package-lock.json 中锁定的精确版本。

这里有两种不同的风险判断。漏洞公告是在匹配已知问题；包不存在、发布较新、包含安装脚本，则是在寻找可疑信号。新包可以完全正常，安装脚本也可能有合理用途，不能把这些命中直接当成恶意结论。

原文没有给出 slopsquatting 的发生频率，也没有展示恶意样本的检出结果。作者提出的攻击路径值得防范，但工具实际拦得多准，还缺数据。

给 AI 接仓库时，配置文件也要审

依赖之外，RepoXray 还检查 .mcp.json 和 claude_desktop_config.json。作者指出，这些文件可能包含明文 token，或者使用未固定版本的 npx -y 执行远程代码。

这两类问题需要分别处理：前者涉及凭证暴露，后者涉及执行对象是否可控。即使配置看起来只是给 AI 接一个工具，也应该检查它最终运行了什么命令。

另一个检查点是 .env。作者关注的是编码代理能够读取这些文件、仓库却没有 .aiignore 的情况。RepoXray 会据此生成定制的 .aiignore、AGENTS.md 防护规则和修复提示词，还会计算活跃 LLM 上下文的膨胀情况。

不过，原文没有解释「活跃上下文」具体如何统计，也没交代生成的规则适配哪些代理。使用前仍需确认自己的工具是否识别 .aiignore，以及 AGENTS.md 中的要求如何被执行。

零上传解决了什么，还剩哪些未知

按作者描述，Web 扫描器通过 File System Access / Drag-and-Drop APIs 读取本地文件，扫描过程 100% 在浏览器 RAM 中运行，向服务器上传的文件数据为 0 bytes。CLI 的入口是 npx rxray .，bundle 为 19 KB，有 0 个运行时依赖。

这些设计降低了试用门槛，也让不愿上传仓库源码的团队有理由进一步了解它。但零文件上传和完全离线是两回事：工具还会实时检查注册表、查询 OSV.dev，原文没有说明这些查询具体发送哪些字段。

同样，体积小、运行时依赖少，是可审查性的有利条件，不能直接证明扫描规则完整或工具自身安全。

我的判断

我认可把依赖检查和 AI 工具配置检查放在同一个入口。对 Node 项目而言，风险不只发生在安装依赖时，也可能出现在接入 MCP、开放工作目录读取权限的时候。

但 RepoXray 更适合作为一次前置排查。原文没有证明它比已有依赖审计、凭证扫描或人工配置审查检出更多问题，也没有说明这些能力之间的覆盖差异。作者正在征求误报和规则缺失方面的反馈，现阶段应按待验证的工具介绍看待。

扫描结果适合用来定位复核对象，不能当成仓库安全的通行证。

尤其是 .aiignore 和 AGENTS.md：生成文件只是起点。代理能否遵守、文件读取是否受到实际限制，需要在使用的工具里确认。

能拿来做什么

• 接手陌生前端或 Node 仓库时，可以在执行 npm install 前检查锁文件版本、近期发布的依赖和 postinstall 行为，逐项复核可疑命中。
• 使用 AI 推荐的新依赖时，先确认包是否真实存在，再核对来源和发布时间；不要只凭名字合理、安装成功就接受它。
• 接入 MCP 前，检查 .mcp.json 或 claude_desktop_config.json 中的明文 token，以及未固定版本的 npx -y 命令。
• 使用生成的 .aiignore 和 AGENTS.md 前，确认当前编码代理如何处理它们，再验证 .env 等敏感文件是否仍可被读取。