🧭 供应链响应速度，才是 Project Glasswing 之后真正的护城河

Anthropic 在 2026 年 5 月 22 日发布了 Project Glasswing 初步更新。约 50 家合作伙伴使用 Claude Mythos Preview，在一个月内发现了超过 10,000 个高危或严重级别漏洞。开源扫描侧，Mythos 在 1,000 多个开源项目中输出了 23,019 个漏洞候选，其中 6,202 个被初步评为高危或严重；在被外部安全机构或 Anthropic 复核的 1,752 个高危或严重候选中，90.6% 被确认是真阳性 (True Positive)。注1

这些数字当然很惊人。但如果只把它理解为“AI 漏洞扫描器变强了”，反而低估了这件事的意义。

在我看来，真正的变化是：网络安全的主矛盾正在迁移。过去的瓶颈在于发现 (Discovery) 和利用 (Exploitation)，现在的瓶颈开始转移到修复 (Remediation)、合入 (Integration)、部署 (Adoption) 和治理 (Governance)。注1

换句话说，AI 找洞的速度已经超过了组织修洞的速度。

---

🔍 Project Glasswing 证明了什么

Project Glasswing 的第一层意义，是验证了前沿模型已经能够进入高价值漏洞研究场景。它不是传统静态扫描器那种“这里可能有问题”的提醒，而是更接近安全研究员的工作循环：理解代码、提出假设、构造 proof of concept (PoC)、验证可利用性，再把发现整理成报告。

Cloudflare 的反馈尤其关键。它在 50 多个内部代码库中测试 Mythos Preview，发现了约 2,000 个 bug，其中 400 个属于高危或严重级别。Cloudflare 也特别强调，有效结果并不是靠“把通用 coding agent 丢进仓库”得到的，而是依赖一套 harness：代码库地图、扫描子代理 (Subagents)、分诊、复核和报告生成。注2

我认为，这说明未来的安全自动化，不只是模型能力竞赛，也是编排能力竞赛。强模型是引擎，但谁能把引擎接入正确的工作流，谁才能把算力变成可落地的安全生产力。

---

🧱 真正的瓶颈不是发现，而是修复后的采用

我不太愿意把这件事上升成“碳基 vs 硅基”的文明叙事。这个说法很抓人，但太容易制造无效恐慌。

更准确的表达是：机器发现速度和组织修复速度之间，出现了新的差距。

一个漏洞从“被模型发现”到“风险真正下降”，中间并不是一句“打补丁”就结束了。它至少要经过几个环节：

1. 上游开源维护者确认问题、判断影响、设计补丁；
2. 下游供应商把上游补丁合入自己的产品版本；
3. 企业客户评估变更风险、安排测试窗口和部署窗口；
4. 安全、研发、运维、业务、合规和管理层共同决定是否接受停机、回滚或临时缓解方案；
5. 补丁还要被广泛部署，而不是停留在公告或工单里。

这就是漏洞管理里最容易被忽略的现实：修复不是一个动作，而是一条供应链。

Anthropic 报告中最有解释力的数据，不是 10,000+，而是开源披露链路中的落差：目前估计已向维护者披露 530 个高危或严重漏洞，其中 75 个已经修补，65 个有公开安全公告。这个数字不能简单解读为“维护者不努力”，它反映的是人类组织系统处理复杂变更的吞吐量有限。注5

在真实世界里，一个负责任的供应商既要拉动上游，也要推动下游。这是一个 Push and Pull 的过程。上游不修，供应商很难干净地合入；供应商不合入，下游客户很难部署；客户不部署，风险仍然留在生产环境里。

所以，Project Glasswing 之后，真正的竞争单位不是单个安全团队，也不是单个厂商，而是整条供应链的响应速度。

---

🌀 用系统动力学看，瓶颈为什么会迁移

系统动力学 (System Dynamics) 的价值，在于它不只看单点能力，而是看变量、连接、反馈环路和延迟。

Project Glasswing 之所以重要，是因为它给原有漏洞管理系统加入了一个强变量：Mythos-class AI。这个变量不只是让某个环节更快，而是改变了整个系统的结构。

🧩 第一层：新变量进入系统

旧系统里，漏洞发现是稀缺能力。高级漏洞研究员、国家级团队、顶级红队和少数安全厂商拥有更强的发现能力，普通组织只能靠扫描器、渗透测试和披露公告慢慢补齐认知。

AI 进入以后，发现能力的边际成本下降，发现频率上升，覆盖范围扩大。过去很多隐藏在开源库、关键基础设施和边缘组件里的技术债务，会被更快暴露出来。

这个变量的直接效果是：系统里的“已知未修漏洞存量”会迅速增加。

🔗 第二层：连接关系发生变化

过去，漏洞发现和漏洞修复之间有一个缓冲区。漏洞研究成本高，披露速度相对慢，很多组织虽然也慢，但整个系统还能勉强维持节奏。

现在，发现端被 AI 压缩到机器速度，但修复端仍然受人类协作限制。于是原本松散连接的环节被突然拉紧：模型发现、人工验证、上游修复、供应商合入、客户部署、审计取证，开始挤在同一个队列里。

这时，安全问题就从技术队列变成治理队列。谁有 owner？谁来判断业务影响？谁批准紧急变更？谁承担回归测试不足带来的生产风险？这些问题比“有没有补丁”更决定风险是否下降。

🔁 第三层：反馈环路开始重写

这里至少有三个反馈环路值得关注。

第一个是负向环路：AI 发现更多漏洞，组织优先级排序更准确，关键漏洞更快被修复，真实暴露面下降。这是 Project Glasswing 最乐观的一面。

第二个是正向风险环路：AI 发现更多漏洞，积压队列变长，维护者疲劳上升，修复质量下降，补丁引入新问题，组织更加谨慎，修复速度进一步下降。这个环路会把“发现能力提升”变成“治理负担增加”。

第三个是不平等环路：拥有模型访问权、自动化 harness 和强治理能力的大型组织，会更快发现并修复自身问题；缺少资源的中小组织和开源维护者则被动等待，安全差距进一步扩大。长期看，这会改变供应链里的权力结构和责任分配。

⏳ 第四层：延迟决定系统风险

漏洞风险最危险的地方，不只是漏洞存在，而是延迟。

从发现到公告有延迟，从公告到补丁有延迟，从补丁到产品版本有延迟，从产品版本到客户部署又有延迟。AI 压缩的是前半段延迟，但后半段如果没有同步压缩，系统会进入一个非常尴尬的阶段：我们看见了更多风险，却暂时没有能力同等速度地消除风险。

这就是 Project Glasswing 暴露出来的真正危险窗口。

---

🏛️ 旧规则的四处裂纹

如果把 Project Glasswing 放进这个系统里看，它带来的不是一个孤立技术冲击，而是让四套旧规则同时开始松动：协调披露、开源维护、监管治理和利益分配。

第一处裂纹：CVD 的慢世界前提失效

传统协调漏洞披露 (Coordinated Vulnerability Disclosure, CVD) 的前提正在被削弱。

CVD 之所以能运行，是因为过去漏洞发现具有一定独占性。研究员发现漏洞后，给厂商一个修复窗口；在这段时间里，漏洞不会自动被全世界同时发现。这个机制默认了一个比较慢的世界：发现慢、复现慢、利用链构造慢，披露节奏因此可以被人为管理。

但 Mythos-class 模型改变了这个前提。如果一个受控模型能批量发现关键项目里的高危漏洞，那么另一个能力相近、约束更少的模型，也可能独立发现相似问题。此时，90 天窗口不再只是保护期，也可能变成已知风险暴露期。CVD 不会立刻破产，但它必须从“给厂商时间修补”升级为“给整个供应链时间完成分诊、缓解、合入、部署和审计”。注3

Linux 社区已经给出了一个很具体的早期样本。Linus Torvalds 在 Linux 7.1-rc4 的发布邮件里公开批评，AI 生成的重复漏洞报告让内核安全邮件列表几乎无法管理；随后多家技术媒体也报道，Linux 项目开始调整安全漏洞报告规则，要求 AI 发现的安全问题不要简单涌入私有安全列表，而要被更负责地验证、去重和提交。注4 这不是某个维护者脾气不好，而是 CVD 旧流程遇到机器规模报告后的真实拥塞。

第二处裂纹：开源维护者变成压力出口

开源生态被推到了更尖锐的位置。

开源软件是现代数字基础设施的地基，但很多关键项目并不是由庞大商业团队维护，而是由少数核心维护者、兼职贡献者和有限基金支撑。AI 大规模发现漏洞，本意是帮助生态变安全；但如果报告、验证、补丁、测试和维护资金没有同步进入，结果可能是另一种悖论：发现越多，维护者越疲惫；维护者越疲惫，修复越慢；修复越慢，暴露窗口越长。

这不是“开源不够努力”，而是系统把更多压力压给了原本就最脆弱的一层。AI 发现能力越强，越不能把开源生态变成供应链的压力释放口。真正负责任的 AI 安全实践，不能只提交漏洞报告，还要尽可能附带可复现证据、最小化 PoC、修复建议、回归测试，甚至资金和人力支持。

Anthropic 自己的初步更新也承认了这点：维护者已经被低质量 AI bug report 冲击，一些维护者甚至要求 Anthropic 放慢披露节奏；在已披露给维护者的 530 个高危或严重漏洞中，目前只有 75 个已经修补。注5 这让 Linux 的例子不再是孤例，而是一个更大生态压力的局部显影。

第三处裂纹：监管者既是裁判，也是能力争夺者

监管者的身份开始变得双重。

监管者过去通常是“出事以后要求治理”的角色：要求企业披露、整改、证明合规。但 Mythos-class 模型让监管者也进入了一个更尴尬的位置：它既要保护本国产业链、金融系统和关键基础设施，也要争取理解这类模型的攻击和防御能力，因为这会影响国家在网络空间里的行动能力。

美国金融监管层的反应已经说明了这种双重性。更准确地说，不是美国商务部单独警告银行，而是美国财政部长 Scott Bessent 和美联储主席 Jerome Powell 在 2026 年 4 月召集华尔街银行 CEO，警示 Anthropic Mythos 及类似模型带来的网络风险；后续报道也显示，美国银行正在加速修补 Mythos 暴露出来的 IT 弱点。注6 与此同时，Axios 报道称 CISA 当时尚未获得 Mythos 访问权，而美国国家网络主管正在推动更广泛的民用机构访问；Anthropic 也曾向 CISA 和商务部介绍 Mythos 能力。注7 这说明监管者不是站在系统外观察，而是正在争夺系统内的能力入口。

欧盟的 Cyber Resilience Act (CRA) 则展示了另一种瓶颈。CRA 的设计初衷，是要求数字产品制造商对已被主动利用的漏洞和严重安全事件承担报告责任：从 2026 年 9 月 11 日起，制造商需要在 24 小时内提交 early warning，72 小时内提交更完整通知，并通过 ENISA 的 Single Reporting Platform 同步路由给相应 CSIRT 和 ENISA。注8 这个制度方向是对的：它迫使供应商负责任。但如果 AI 让漏洞发现速度提升几个数量级，监管平台和 CSIRT 自己也可能成为新的排队系统。所有供应商都开始上报时，谁来判断优先级？谁来识别系统性风险？谁来决定哪些漏洞需要跨行业协调？监管者原本想减少信息黑箱，却可能被突然放大的信息流变成新的治理瓶颈。

第四处裂纹：所有人的位置被重新定价

各个利益相关方的行为会开始分化。

大型平台和核心供应商会把 Mythos-class 能力视为提前发现系统性风险的机会；开源维护者会担心自己被高质量和低质量报告一起淹没；传统渗透测试厂商会发现“找洞”本身正在被商品化，价值必须迁移到验证、解释、修复落地和审计证据；董事会、监管者和保险机构会开始追问 AI finding 如何被验证、排序、授权、修复和接受；攻击者和红队则会争夺类似能力，把漏洞发现和利用链构造继续自动化。

我发现，这些态度看起来分散，背后其实是同一个系统变化：当发现能力突然变便宜，所有人的位置都会被重新定价。

---

🛡️ 企业要做的不是等待自动修复，而是先提高响应韧性

全自动修复 (Autonomous Auto-Patching) 当然是一个方向。未来的理想闭环可能是：AI 发现漏洞，AI 生成补丁，AI 完成兼容性测试，AI 推动灰度发布和回归验证。

但这不是大多数企业今天可以直接押注的答案。

原因很简单：修复代码不是孤立动作。它可能影响兼容性、性能、客户环境、合规承诺和业务连续性。一个自动生成的补丁即使修好了安全问题，也可能破坏某个关键业务路径。安全上正确，不等于系统上可接受。

因此，短期更现实的策略不是“把修复完全交给 AI”，而是把组织响应和技术缓解同时提速。

对企业来说，至少要做三件事。

第一，重建漏洞分诊 (Triage) 机制。不要把 AI 发现全部变成同等优先级的工单，而要按可达性、暴露面、资产重要性、利用难度、补偿控制和业务影响排序。

第二，把 mitigation、detection、separation、isolation 前置。补丁彻底落地需要时间，但临时缓解、检测规则、网络隔离、访问控制、多因素认证 (Multi-Factor Authentication, MFA)、日志和监控可以先降低可利用性。

第三，把漏洞管理升级为高层治理议题。董事会和管理层不应该只问“还有多少漏洞没修”，而要问：关键漏洞从发现到验证需要多久？从验证到 owner 分派需要多久？从补丁可用到生产部署需要多久？哪些风险被正式接受？接受依据是什么？

这才是 AI 时代漏洞治理的核心指标。

---

🧭 不同角色应该如何应对

如果前面四处裂纹成立，那么应对方式就不能只是“更快打补丁”。不同角色要回应的，是自己在这四条裂纹中的位置。

企业安全负责人：修复漏洞入口

对企业安全负责人来说，核心任务是修复 CVD 旧流程的失速问题。不要把每一个 AI finding 都当成普通 CVE 工单处理，而要建立新的漏洞入口规则：报告必须可复现、可去重、可追踪 owner、可映射到资产和业务暴露面。你的问题不再是“能不能发现更多漏洞”，而是“组织能不能吸收这些发现”。

供应商：做供应链的传导器

对供应商来说，核心任务是认清自己在供应链中的身份。供应商不是孤立节点，而是上游、产品和客户之间的传导器：既要向上 pull，上游有漏洞就要推动源头修复；也要向下 push，补丁合入后要推动客户理解、测试和部署。这个角色不能只转发公告，而要把漏洞报告转化为补丁、测试、版本、客户通知、部署证据和残余风险说明。

这里还要区分供应链龙头和非龙头企业。龙头企业要承担带头作用：它一动，龙身龙尾才会跟随。它需要定义接口、节奏、披露规则、补丁优先级和客户沟通模板，把整条链条带起来。非龙头企业则要跟好龙头，加强和上游、下游的紧密连接，缩短自己在链条中的反应时间。漏洞响应不再是单点英雄主义，而是整条供应链共同应对的组织能力。

开源生态：别让维护者当人工缓冲区

对开源生态来说，核心任务是避免把维护者变成 AI 漏洞洪水的人工缓冲区。行业需要更现实地面对维护者资源问题：AI 报告应当默认包含复现步骤、影响分析、去重证据、最小补丁建议和测试用例；大型平台和商业用户也应当通过资金、工程人力或基金会机制参与修复。如果 AI 大规模发现开源漏洞，却没有同等规模的验证、补丁、测试和资助机制，那么 “发现越多，生态越安全”就不一定成立。

监管者：用源头规则提高行业响应速度

对监管者来说，核心任务是避免自己成为新的信息瓶颈，同时把监管的杠杆用在源头上。第一，监管要推动企业背负起基本的网络安全实践：资产可见性、漏洞处理流程、补丁管理、事件报告、SBOM 和供应链责任，都不能停留在口号里。

第二，监管要加快所在国行业供应链的漏洞响应能力。监管是在源头治水，它制定的规则有牵一发动全身的力量；如果它能把报告格式、优先级、去重机制、跨行业共享边界和 CSIRT 协调机制设计好，就能让整个产业链的响应速度一起提高。

第三，监管也要争取缓解能力不平等，帮助本国关键基础设施获得关键模型的访问能力、防御能力和威胁情报。否则，模型访问权本身就会变成新的安全分层。

董事会：从漏洞数量转向风险吞吐量

对董事会和风险管理者来说，核心任务是把漏洞管理从数量指标改成吞吐量指标。不要只问“还有多少漏洞没修”，而要问：哪些 AI finding 被验证？哪些进入紧急修复？哪些用缓解控制临时覆盖？哪些风险被正式接受？谁批准？何时复核？从治理视角看，真正的 KPI 不是 backlog 数字，而是风险从发现到下降的周期。

安全厂商与专家：价值迁移到验证、编排和理解

对传统安全厂商来说，核心任务是接受价值链迁移。机会不是继续卖更厚的扫描报告，而是帮助客户完成验证、优先级排序、攻击路径确认、补丁编排和合规证据。AI 会压低“发现漏洞”的价格，但会提高“把漏洞变成可治理风险”的价值。

对独立安全专家来说，核心任务是尽早接触和理解这类强模型。不是为了炫技，也不是为了制造恐慌，而是为了理解下一代攻击者和防御者都会拥有什么工具。越早上手，越能判断哪些能力是真突破，哪些只是演示效果。

---

🔮 三种可能的未来

未来一：失控的积压未来

AI 继续提高漏洞发现速度，但 CVD 流程没有升级，开源维护者继续被报告淹没，供应商只转发公告，监管平台也变成新的排队系统。攻击方更快获得类似 Mythos-class 的能力，而大量组织还停留在月度补丁、人工审批和被动公告机制里。结果不是漏洞减少，而是已知未修风险迅速堆积，安全团队每天都更忙，但系统风险并没有真正下降。

未来二：更可能发生的不平等未来

安全能力不再均匀分布，而是沿着模型访问权、工程编排能力、供应链位置和组织治理成熟度继续分化。大型平台、供应链龙头和高成熟度企业获得更强模型、更好 harness、更快治理能力和更强监管沟通能力；中小组织、边缘供应商和资源不足的开源项目，则只能在公开公告、滞后补丁和有限预算里被动追赶。

这不是一个“中性”的未来，只是一个更接近现实世界运行方式的未来。现实世界里，许多议题已经越来越难取得 middle ground：左派和右派、民粹和建制、大国和小国、平台和个体之间，达成共识的空间都在缩小。Project Glasswing 可能会把类似的结构带进网络安全领域：强者拥有更早的可见性，弱者暴露在更长的风险延迟里。

未来三：协同的韧性未来

行业补齐配套能力。CVD 从单个厂商修补窗口，升级为供应链分诊、缓解、合入、部署和审计的协同机制；开源生态获得验证、补丁、测试、资金和维护人力；监管者用源头规则加速本国产业链响应，而不是只增加表格和报告；供应链龙头主动带动节奏，非龙头企业提高连接密度；AI 不只是发现漏洞，也帮助分诊、生成补丁、写测试、做回归、提供审计证据。到那时，Project Glasswing 可能不是安全危机的开端，而是软件韧性升级的起点。

我的判断：三种未来会并存

我更倾向于把这三种未来都看作可能同时发生的局部现实。成熟组织和强供应链可能进入第三种未来，资源不足的组织可能被困在第一种未来，而整个行业的平均状态，大概率会长期停在第二种：一个不平等加剧、但又最像现实的中策。

---

---

✨ 结语：能跑起来的供应链，才有资格谈安全

过去，我们常说安全是一场攻防竞赛。现在看，这句话还不够准确。

AI 时代的漏洞管理，更像是一场供应链响应竞赛。模型负责把隐藏的风险照出来，但能不能把风险真正降下去，取决于上游、供应商、客户、管理层、开源维护者和监管者能不能一起跑。

在这个新系统里，最危险的组织不是没有看到漏洞的组织，而是看到了漏洞，却没有能力把它们转化为行动的组织。最有韧性的供应链，也不是没有漏洞的供应链，而是龙头愿意带动、成员愿意跟进、监管能够源头治水、开源能够得到支撑、风险能够快速从发现变成修复和缓解的供应链。

---

参考文献与注释

1. 注1： Anthropic 在 Project Glasswing 初步更新中披露：约 50 家合作伙伴在一个月内使用 Claude Mythos Preview 发现 10,000+ 个高危或严重漏洞；开源侧扫描 1,000+ 个项目，输出 23,019 个候选漏洞，其中 6,202 个被初步评为高危或严重；1,752 个被复核候选中 90.6% 为 true positive。Anthropic 也明确指出，软件安全进展的瓶颈正在从“发现漏洞”转向“验证、披露和修补 AI 发现的大量漏洞”。参见 Anthropic, “Project Glasswing: An initial update,” 2026-05-22, https://www.anthropic.com/research/glasswing-initial-update

2. 注2： Cloudflare 在 Project Glasswing 复盘中披露，它将 Mythos Preview 指向 50 多个内部 repository，发现约 2,000 个 bug，其中约 400 个为高危或严重级别；Cloudflare 同时强调，通用 coding agent 直接扫 repo 覆盖率不足，真正有效的是围绕模型建立 recon、hunt、validate、dedupe、trace、report 等多阶段 vulnerability discovery harness。参见 Cloudflare, “Project Glasswing: what Mythos showed us,” 2026-05-18, https://blog.cloudflare.com/cyber-frontier-models/

3. 注3： Anthropic 在同一篇初步更新中解释，软件行业长期惯例是在发现漏洞后约 90 天披露，或在补丁可用后约 45 天披露；但在 Mythos-class 能力下，公开披露数据本身已经成为 AI 网络能力前沿的滞后指标。参见 Anthropic, “Project Glasswing: An initial update,” 2026-05-22, https://www.anthropic.com/research/glasswing-initial-update

4. 注4： The Register / Tom’s Hardware 等媒体均报道了 Linus Torvalds 在 Linux 7.1-rc4 发布邮件中对 AI 生成漏洞报告洪水的批评，核心问题是重复报告让 Linux kernel security list 近乎无法管理，并推动 Linux 调整 AI 辅助漏洞报告规则。参见 The Register, “Linus Torvalds says AI-powered bug hunters have made Linux security mailing list ‘almost entirely unmanageable’,” 2026-05-18, https://www.theregister.com/security/2026/05/18/linus-torvalds-says-ai-powered-bug-hunters-have-made-linux-security-list-almost-entirely-unmanageable/5241633/；Tom's Hardware, “Linus Torvalds says flood of duplicate AI-generated vulnerability reports have made Linux security mailing list ‘almost entirely unmanageable’,” 2026-05-18, https://www.tomshardware.com/software/linux/linus-torvalds-says-ai-bug-reports-have-made-linux-security-list-almost-entirely-unmanageable

5. 注5： Anthropic 在 Project Glasswing 初步更新中写到，维护者已经面对低质量 AI bug report 的洪水，一些维护者要求 Anthropic 放慢披露速度；其开源扫描链路中，估计已向维护者披露 530 个高危或严重漏洞，其中 75 个已修补。参见 Anthropic, “Project Glasswing: An initial update,” 2026-05-22, https://www.anthropic.com/research/glasswing-initial-update

6. 注6： 更准确的公开报道口径是美国财政部长 Scott Bessent 与美联储主席 Jerome Powell 召集银行 CEO 讨论 Mythos 风险，而非美国商务部单独向银行发出修复命令。参见 Bloomberg, “Anthropic Model Scare Sparks Urgent Bessent, Powell Warning to Bank CEOs,” 2026-04-10, https://www.bloomberg.com/news/articles/2026-04-10/anthropic-model-scare-sparks-urgent-bessent-powell-warning-to-bank-ceos；Reuters, “Anthropic’s Mythos sends US banks rushing to plug cyber holes,” 2026-05-12, via The Star, https://www.thestar.com.my/tech/tech-news/2026/05/13/anthropic039s-mythos-sends-us-banks-rushing-to-plug-cyber-holes

7. 注7： Axios 报道称 CISA 当时尚未获得 Mythos Preview 访问权，尽管部分政府机构已经在使用；美国国家网络主管 Sean Cairncross 等官员正在推动更广泛的民用机构访问，Anthropic 也曾向 CISA 和商务部 brief Mythos 能力。参见 Axios, “Scoop: CISA lacks access to Anthropic’s Mythos,” 2026-04-21, https://www.axios.com/2026/04/21/cisa-anthropic-mythos-ai-security

8. 注8： 欧盟委员会和 ENISA 对 Cyber Resilience Act reporting obligations 的说明显示，2026-09-11 起，制造商需通过 ENISA Single Reporting Platform 报告 actively exploited vulnerabilities 和 severe incidents；早期警告为 24 小时，完整通知为 72 小时。参见 European Commission, “Cyber Resilience Act - Reporting obligations,” https://digital-strategy.ec.europa.eu/en/policies/cra-reporting；ENISA, “Single Reporting Platform (SRP),” https://www.enisa.europa.eu/topics/product-security-and-certification/single-reporting-platform-srp

---