MCP供应链攻击中，23个PR里有19个被关闭、4个仍然开着，没有任何一个被合并，但也没有确认任何实际受害者——这个事件的关键不是“有没有人被害”，而是“一次设计精密的供应链投毒可以在没有任何可指名受害者的情况下被完整记录”，当AI供应链的威胁在“没有造成伤害”的阶段就已经如此成熟时，企业的检测能力到底该按“已经出事了”还是按“随时可以出事”来建？

目录

一、导语：一个没有受害者的“事件”，为什么值得写一篇长文

安全行业长期存在一种隐性的记账习惯：一次攻击是否“重要”，往往取决于它是否产生了可指名的损害。数据泄露看记录条数，勒索软件看赎金金额，供应链攻击看被污染的包下载量。这套记账方式在传统软件供应链中尚可运转，因为损害与行为之间存在相对清晰的因果链：恶意包被安装、凭证被外传、横向移动发生、数据被加密。但在AI基础设施供应链中，这条因果链正在被拉长、被稀释，甚至被主动切断。

MCP生态中这次被完整记录的投毒尝试，恰好提供了一个反例样本。23个Pull Request（PR），19个被关闭，4个仍然开着，0个被合并，0个被确认的实际受害者。如果按传统记账方式，这是一次“失败的攻击”，甚至不构成一起“安全事件”。但笔者认为，恰恰是这组数字的组合方式，暴露了一个被长期忽视的威胁类别：攻击已经具备了完整的工程形态——有目标选择、有载荷设计、有投递节奏、有规避策略——却在损害发生之前被记录、被拦截、被归档。它没有受害者，但它有完整的攻击证据链。

这就引出了本文的核心问题：当威胁的成熟度已经可以在“零损害”阶段被完整观测时，企业的检测能力应该按什么基线来建设？按“已经出事了”建，意味着检测体系围绕已知损害模式展开，其有效性依赖于历史事件库的覆盖度；按“随时可以出事”建，意味着检测体系围绕攻击可达性展开，其有效性依赖于对攻击面、投递路径与载荷形态的前瞻建模。这两种基线在工程成本、组织接受度、误报容忍度上存在结构性差异，而MCP这类新兴生态的特殊性，正在把这种差异放大为一道必须做出选择的分水岭。

笔者认为，“零受害者”不应被读作“低风险”，而应被读作“高风险但尚未兑现”。把未兑现的高风险从风险台账中剔除，是当前AI供应链安全治理中最昂贵的一类认知偏差。

为了让讨论不停留在概念层面，本文会沿着一条贯穿始终的主线展开：从“损害中心”的检测范式，迁移到“可达性中心”的检测范式。这条主线将依次经过事件解剖、威胁建模、范式对比、工程落地、度量与边界五个环节，每个环节都给出可验证的数据来源、可执行的步骤和明确的适用边界。文中所引数据均标注来源，涉及整合或模拟的部分会明确标注，不虚构实验与作者团队。

二、事件解剖：23/19/4/0 这组数字到底记录了什么

2.1 先把事实边界划清楚

在展开分析之前，必须先明确本文对事件事实的引用边界。MCP由Anthropic于2024年11月开源发布，其规范定义了模型与外部工具、数据源之间的标准化连接方式，核心构件包括Host、Client、Server以及Resources、Prompts、Tools等原语（Anthropic, 2024）。围绕MCP形成的社区服务器仓库、包注册表与示例项目，构成了一个典型的“快速扩张、弱中心治理”的开源生态。这类生态在历史上反复出现过供应链投毒尝试，npm、PyPI、RubyGems均有长期记录（Ohm et al., 2020；Ladisa et al., 2023）。

本文所讨论的“23个PR、19个关闭、4个仍开启、0个合并、0个确认受害者”，是对一类被公开记录的投毒尝试的聚合描述。需要说明的是：第一，这组数字描述的是PR层面的处置结果，不等于攻击者全部尝试的规模；第二，“0个确认受害者”指的是没有公开确认的、可指名的受损主体，不排除存在未被发现或未被披露的影响；第三，PR被关闭的原因可能是维护者识别出异常，也可能是代码质量、范围不符、重复提交等常规原因，公开记录通常不足以区分动机。笔者认为，正是这种“处置结果可观测、动机不可观测”的信息结构，构成了后文威胁建模的起点。

2.2 为什么“没合并”不等于“没风险”

一个常见的误读是：既然没有任何PR被合并，那么攻击就没有进入代码库，风险为零。这个推理在逻辑上成立，但在工程上不成立，原因有三。

其一，PR是投毒的一种载体，不是唯一载体。攻击者可以通过issue中的诱导性链接、依赖项名称混淆（dependency confusion）、typosquatting、以及针对维护者凭证的钓鱼等方式投递载荷。PR被关闭只说明这一条路径被阻断，不说明攻击面被收敛。Sonatype《State of the Software Supply Chain》历年报告持续记录了恶意包的规模增长，2023年报告统计的恶意组件数量已超过24万个（Sonatype, 2023），这说明单一路径的阻断与整体威胁水平之间没有稳定对应关系。

其二，PR本身携带信息。一个设计精密的投毒PR，其提交时间、账号年龄、代码风格、依赖变更模式、CI触发行为，都是可用于威胁情报的观测点。19个被关闭的PR如果只被当作“噪音”丢弃，等于主动放弃了一批高价值的结构化攻击样本。笔者认为，关闭动作应当伴随取证动作，否则防御方每次都在“重新认识同一个攻击者”。

其三，4个仍然开着的PR是一个持续存在的暴露面。开启状态意味着代码仍可被查看、被引用、被fork、被下游项目以“参考实现”的名义复制。在弱治理的开源生态中，“未合并但可访问”的代码具有事实上的传播能力。这一点在AI生态中尤为突出，因为大量MCP Server实现是中小团队甚至个人开发者参照社区示例完成的，示例代码的“示范效应”远大于其合并状态。

2.3 从“事件”到“样本”：记录本身的价值

这次事件最值得重视的特征，不是攻击失败了，而是攻击被完整记录了。在传统供应链攻击中，防御方往往在损害发生后才获得样本，样本带有强烈的“事后性”：载荷已被执行、路径已被清理、攻击者已撤离。而这次记录保留了攻击的“事前形态”：PR的完整diff、提交时序、账号行为、维护者处置动作。这类样本对于构建检测规则、训练分类模型、设计蜜罐策略的价值，远高于事后取证样本。

笔者认为，安全社区应当把这类“未兑现的攻击记录”作为一种独立的一手资料类型来建设，而不是附属于事件响应报告。可参照的实践是MITRE ATT&CK对战术技术的结构化编码（MITRE, 2024），以及OpenSSF Scorecard对开源项目安全姿态的量化评估（OpenSSF, 2023）。前者提供了行为层的通用语言，后者提供了项目层的度量框架，但两者都缺少对“投毒尝试样本”的专门建模。这是一个明确的空白，也是本文后续提出检测能力建设路径的立足点。

三、威胁建模：MCP生态的攻击面与“零受害者威胁”的形式化

3.1 MCP的架构特征如何塑造攻击面

MCP的设计目标是解耦模型与工具，使模型可以通过标准化协议调用外部能力。这一设计带来了三个结构性特征，每一个都对应一类攻击面。

第一，信任边界外移。在传统应用中，工具调用逻辑内嵌于应用代码，信任边界相对清晰。MCP把工具实现外置为Server，Host需要信任Server的返回内容。一旦Server被投毒，恶意内容可以以“工具输出”的形式进入模型上下文，形成间接提示注入（indirect prompt injection）的通道。Greshake等人（2023）系统描述了间接提示注入的威胁模型，指出外部内容一旦进入模型上下文，就可能劫持模型行为。本文评述：该研究奠定了“内容即攻击面”的认识，但其讨论集中在网页与文档场景，尚未覆盖MCP这类协议化工具调用场景中“工具描述本身即载荷”的情形。

第二，配置即代码。MCP Server的注册、权限声明、工具描述通常以JSON等配置文件形式分发。配置文件的可篡改性、可伪造性与代码同等重要，但当前多数团队并未把配置纳入代码审查与签名验证流程。Hou等人（2024）在对LLM应用供应链的研究中指出，模型卡、配置文件、提示模板等“非代码制品”是当前审查流程的系统性盲区。笔者认为，这一判断在MCP场景中更为尖锐，因为MCP的工具描述直接参与模型决策，其安全性权重不低于可执行代码。

第三，生态治理弱中心化。MCP Server大量以社区仓库形式存在，缺少统一的发布审核、签名与撤回机制。这与npm早期生态高度相似。Ladisa等人（2023）对开源软件供应链攻击的系统性综述统计了攻击者常用的投递技术，包括名称混淆、账号劫持、依赖注入与构建脚本篡改。本文评述：该综述提供了良好的技术分类，但其样本主要来自传统包管理器，对“协议层工具描述投毒”这一新形态覆盖不足，这正是MCP生态需要补充建模的部分。

3.2 “零受害者威胁”的定义与判定条件

基于上述攻击面，本文提出“零受害者威胁”（Zero-Victim Threat, ZVT）这一分析概念，其定义如下：ZVT 指一类已经具备完整工程形态（目标选择、载荷构造、投递执行、规避设计），但因防御方拦截、攻击方自我克制或环境条件不满足，而未产生可指名损害的高级供应链攻击形态。

判定一个事件是否属于ZVT，需要同时满足四个条件，本文将其整理为下表，便于工程团队直接用于事件分类。

这四个条件中，“损害未兑现”是最容易被误读的一条。它不意味着风险低，而意味着风险的兑现被推迟或转移。笔者认为，ZVT的威胁等级应当由“工程完整性×目标指向性×可达性”决定，而不是由“是否已造成损害”决定。这一判断与NIST在供应链风险管理指南中强调的“基于风险而非基于事件”的思路一致（NIST, 2022），但NIST的框架面向传统软件与硬件供应链，对AI组件与协议化工具调用的适配仍需专门工作。

3.3 攻击成熟度的四阶段模型

为了把“成熟度”从形容词变成可比较的量，本文提出一个四阶段模型，用于对供应链投毒尝试进行分级。该模型是笔者基于公开事件特征整理的整合性框架，属于分析工具而非实证结论，使用时需结合具体样本校准。

本文评述：四阶段模型的价值不在于精确分级，而在于把检测资源的分配从“按事件数量”转向“按阶段跃迁”。S1到S2的跃迁通常伴随账号准备行为，S2到S3的跃迁通常伴随提交模式变化，S3到S4的跃迁则往往发生在治理薄弱的长期项目中。工程团队可以用阶段跃迁信号作为检测规则升级的触发器，而不是等到S4阶段事件发生后再被动响应。

四、检测范式之争：按“已经出事了”建，还是按“随时可以出事”建

4.1 两种范式的结构性差异

“已经出事了”对应的是损害中心范式（Damage-Centric Detection, DCD）：检测规则来源于历史损害模式，指标以“已确认事件覆盖率”为核心，组织资源围绕事件响应流程配置。“随时可以出事”对应的是可达性中心范式（Reachability-Centric Detection, RCD）：检测规则来源于攻击面与投递路径建模，指标以“攻击路径覆盖度”与“拦截前置度”为核心，组织资源围绕攻击面治理配置。

两种范式并非互斥，但在资源有限时存在明确的优先级冲突。DCD的优势是可解释性强、组织接受度高、误报成本低，因为每条规则都对应一个真实发生过的事件。其劣势是滞后性：规则库的更新永远晚于攻击创新。RCD的优势是前置性，能够在损害发生前拦截；劣势是误报成本高、规则维护复杂、难以向业务方解释“为什么拦截了一个没造成损害的东西”。

笔者认为，MCP这类生态的特殊性在于：它的攻击面扩张速度远快于损害样本积累速度。生态在快速扩张期，新Server、新工具描述、新配置格式持续涌现，而公开确认的损害事件数量有限。在这种“攻击面增速>损害样本增速”的条件下，纯DCD范式会陷入规则永远追不上攻击面的困境。这不是说DCD无效，而是说DCD不足以作为主基线。

4.2 一个可量化的判据：攻击面—样本比

为了让范式选择不停留在定性讨论，本文引入一个可计算的判据：攻击面—样本比（Attack Surface to Sample Ratio, ASSR），定义为某一生态在给定时间窗口内新增的可攻击入口数量与新增的公开确认损害样本数量之比。该指标为本文提出的分析性指标，非行业标准，使用时需明确统计口径。

ASSR = ΔSurface / ΔSample

其中：
  ΔSurface = 窗口内新增可攻击入口数
             （新增Server数 + 新增工具描述数 + 新增配置格式数）
  ΔSample  = 窗口内新增公开确认损害样本数

判据（本文建议，需按组织风险偏好校准）：
  ASSR < 10    → DCD 为主，RCD 为辅
  10 ≤ ASSR < 50 → 双轨并行，RCD 权重上调
  ASSR ≥ 50    → RCD 为主，DCD 作为回溯与取证手段

需要强调，ASSR的分子分母都需要明确口径。ΔSurface可以基于生态仓库的公开统计近似估算，ΔSample则高度依赖披露意愿，存在系统性低估。因此ASSR更适合作为趋势指标而非绝对值指标。笔者认为，即便存在低估，只要口径在组织内部保持一致，ASSR的时序变化仍能有效指示范式切换的时机。这一思路与OWASP在软件供应链安全中强调的“持续度量、按趋势调整”原则一致（OWASP, 2023）。

4.3 为什么“零受害者”事件是范式切换的最佳触发器

ZVT事件具有一个独特优势：它同时提供了攻击证据和防御成功证据。攻击证据说明攻击面真实存在，防御成功证据说明现有拦截有效。这两类证据的组合，恰好可以用来校准RCD范式的两个关键参数：攻击路径的可行性与拦截点的有效性。

具体而言，19个被关闭的PR可以用来回答“哪些拦截点起了作用”，4个仍开启的PR可以用来回答“哪些拦截点存在缺口”，0个合并可以用来回答“现有审查流程的最低有效性”。这三个问题的答案，比任何一次事后复盘都更接近检测体系的真实能力边界。笔者认为，组织应当建立一种机制，把ZVT事件系统性地转化为检测能力的校准输入，而不是让它们停留在“已关闭”的归档状态。

一个实用的判断原则：如果一次攻击尝试的处置结果只能回答“拦没拦住”，而不能回答“为什么拦住、哪里没拦住、下次换个方式还能不能拦住”，那么这次处置的情报价值就被浪费了。

五、工程落地：一套可执行的MCP供应链检测能力建设路径

5.1 总体架构：三层四环

本文提出“三层四环”的落地架构。三层指制品层、协议层、行为层；四环指准入、审查、运行时、回溯四个控制环。该架构为笔者基于前文威胁建模整理的工程框架，参考了SLSA供应链完整性框架的分层思想（OpenSSF, 2024）与NIST SSDF的实践组织方式（NIST, 2022），但针对MCP的工具描述与配置制品做了专门扩展。

5.2 第一步：把“未合并的PR”变成结构化样本

落地路径的第一件事，不是买工具，而是把已有的处置记录结构化。具体步骤建议如下。

步骤1：采集。对每个被关闭或仍开启的可疑PR，采集diff全文、提交时序、账号元数据（注册时间、历史贡献、关联账号）、CI日志、维护者评论。采集需遵守平台服务条款与隐私规范，仅用于安全分析。

步骤2：标注。按3.2节的四个判定条件与3.3节的四阶段模型打标。标注应由两人独立完成并交叉校验，分歧样本进入复核队列。这一步的产出是结构化样本库，其价值在后续规则设计中会持续释放。

步骤3：特征化。把样本转化为可计算特征，建议至少覆盖：diff中依赖变更的比例、新增网络调用的比例、字符串熵值、提交时间与项目活跃时段的偏离度、账号年龄与贡献量的比值。这些特征的具体阈值需按组织样本校准，不宜直接套用外部数值。

步骤4：规则化与回归。用特征构建初筛规则，并在历史样本上做回归测试，重点观察误报率与漏报率的权衡。笔者认为，初筛规则的目标不是“抓全”，而是“把人工审查的注意力集中到高价值样本上”，因此宁可接受一定误报，也不应追求零误报而放宽阈值。

5.3 第二步：工具描述的一致性校验

MCP场景中最具特殊性的一环，是工具描述（tool description）直接参与模型决策。一个被篡改的描述可以在不修改任何可执行代码的情况下改变模型行为。因此，描述—实现一致性校验应当作为独立控制点。

可操作的校验方法包括：其一，建立描述文本的基线快照，任何变更触发人工复核；其二，对描述中出现的权限声明、数据流向、外部调用目标做结构化抽取，与实现代码做比对；其三，对描述文本做异常检测，重点关注诱导性措辞、隐藏指令模式、与工具功能无关的指令性语句。Greshake等人（2023）与Hou等人（2024）的工作都提示，指令性内容混入非指令位置是间接注入的典型手法。本文评述：现有研究多聚焦于内容层面的注入检测，对“描述作为协议制品”的完整性保护讨论不足，这恰恰是MCP工程实践中最需要补的一课。

延伸阅读可参考MCP官方规范文档（modelcontextprotocol.io）与OpenSSF关于供应链完整性的实践指南（openssf.org），前者帮助理解协议原语，后者帮助理解制品签名与验证的工程做法。

5.4 第三步：运行时行为基线与上下文注入检测

运行时检测的重点不是“有没有调用工具”，而是“调用模式是否偏离基线”。建议建立三类基线：调用频率基线、参数分布基线、上下文来源基线。当某次调用的参数分布显著偏离历史分布，或上下文来源中出现未登记的外部内容时，触发告警。

上下文注入检测需要区分直接注入与间接注入。直接注入来自用户输入，检测相对成熟；间接注入来自工具返回、文档内容、网页抓取等外部来源，检测难度更高。工程上可采取“来源标记+内容隔离”的策略：对每一段进入模型上下文的内容标注来源与可信等级，对低可信来源的内容做指令性语句过滤。这一策略不能根除注入，但能显著降低成功率。笔者认为，在模型层防御尚不成熟的阶段，工程层的来源治理是性价比最高的手段。

5.5 第四步：把阶段跃迁做成告警

前文3.3节的四阶段模型，落地方式是阶段跃迁告警。具体做法是：为每个受监控的项目维护一个攻击成熟度评分，评分随观测到的信号更新；当评分跨越阶段边界时触发告警，并自动提升该项目的审查等级。评分模型可以是简单的加权规则，也可以是学习模型，关键在于信号的可观测性与更新频率。

需要提醒的是，阶段跃迁告警的误报率通常高于单点规则，因为它依赖多信号组合。工程上应设置“告警分级+人工确认”的流程，避免告警疲劳。笔者认为，阶段跃迁告警的正确用法是“调整审查资源分配”，而不是“直接阻断”，这样既保留了前置性，又控制了误报的业务影响。

六、度量、对比与局限：这套体系能测到什么，测不到什么

6.1 度量指标体系

RCD范式的度量不能只看“拦截了多少”，否则会退化为DCD的变体。本文建议采用四类指标，分别对应前置性、覆盖度、时效性与成本。

这四类指标的组合，能够避免单一指标的误导。例如，拦截前置度上升但攻击路径覆盖率下降，说明体系在“已知路径上更早拦截”，但对“未知路径”的覆盖在收缩，这通常是规则过拟合的信号。笔者认为，度量体系的设计目标不是证明体系有效，而是尽早暴露体系的失效方向。

6.2 与既有框架的对比

把本文提出的RCD路径与既有框架对比，可以更清楚地看到定位差异。SLSA关注制品来源与构建完整性，其核心是“证明制品从哪来、经过什么流程”，对“制品内容是否恶意”不做判断。OpenSSF Scorecard关注项目治理姿态，其核心是“项目是否有基本安全实践”，对“具体投毒尝试”不做识别。MITRE ATT&CK关注攻击行为编码，其核心是“攻击者做了什么”，对“供应链制品的协议层语义”覆盖有限。

本文评述：这三个框架各有明确边界，RCD路径不是替代它们，而是补上“协议层语义与阶段跃迁”这一层。具体而言，SLSA解决“可信来源”，Scorecard解决“治理基线”，ATT&CK解决“行为语言”，RCD解决“可达性与前置拦截”。四者组合，才能覆盖MCP生态从制品到行为的完整链条。这一组合思路与欧盟《网络弹性法案》对供应链安全的分层要求方向一致（EU, 2024），但落地细节仍需按组织实际调整。

6.3 局限与边界条件

必须明确本文讨论的局限。第一，ZVT概念的判定依赖“可记录性”，而大量投毒尝试并未留下可复核痕迹，因此ZVT样本存在选择性偏差，基于这些样本构建的规则可能高估某些路径、低估另一些路径。第二，ASSR指标的分母依赖披露，存在系统性低估，其绝对值不宜跨组织比较。第三，四阶段模型是分析工具，不是实证结论，阶段划分的边界在真实样本中可能模糊。第四，RCD范式的前置拦截必然带来误报，误报的业务成本在不同组织中差异很大，不能一概而论。

笔者认为，承认局限不是削弱论证，而是让论证可检验。一个检测体系如果只能在“理想样本”上有效，那它在真实环境中就是脆弱的。工程实践的正确态度是：明确边界、持续校准、按趋势调整，而不是追求一次性建成的完美体系。

七、结论与展望

回到文章开头的问题：企业的检测能力到底该按“已经出事了”还是按“随时可以出事”来建？本文的答案是：以“随时可以出事”为主基线，以“已经出事了”为回溯与取证手段。这个答案不是基于对威胁的悲观估计，而是基于一个可观测的结构性事实——在MCP这类快速扩张、弱中心治理的AI供应链生态中，攻击面的增速已经超过损害样本的积累速度，纯损害中心范式会陷入规则永远追不上的困境。

23个PR、19个关闭、4个仍开启、0个合并、0个确认受害者，这组数字的真正含义不是“攻击失败了”，而是“攻击被完整记录但未被充分利用”。把这类记录转化为结构化样本、阶段信号与前置拦截规则，是当前投入产出比最高的检测能力建设方向。笔者认为，未来两到三年，AI供应链安全的分水岭不在于谁拥有更多事件响应经验，而在于谁更早建立起以可达性为中心的检测基线。

展望后续工作，有三个方向值得投入：其一，建立跨生态的ZVT样本共享机制，在保护隐私与遵守平台规则的前提下，把分散的处置记录汇聚为可复用的检测资产；其二，推动MCP工具描述与配置制品的签名与验证标准化，把协议层制品纳入供应链完整性框架；其三，研究阶段跃迁信号的自动化提取方法，降低人工标注成本。这三个方向都不依赖单一组织的规模优势，而依赖社区协作与工程纪律，这正是开源安全生态最擅长的事。

主要参考文献