后 Mythos 时代：自动化漏洞挖掘的七个趋势
几个月前，我在《自动化漏洞挖掘：过去、现在与未来》中写到，AI 自动化漏洞挖掘正在从“代码分类”走向“LLM 辅助传统工具”，再走向“Agentic 代码审计”。当时的核心判断是：真正重要的不是某个模型能不能在代码片段上判断漏洞，而是它能不能像安全研究员一样主动探索、调用工具、提出假设并验证假设。
几个月过去，这个方向的变化比预期更快。
Anthropic 发布 Claude Mythos Preview，并启动 Project Glasswing 后，AI 自动化漏洞挖掘不再只是安全圈内部的技术话题，而开始进入头部厂商、关键基础设施参与方和部分治理讨论的视野。很多人把这个时刻理解为：Mythos 的模型能力突破了某个关键临界点。
我认为，这个判断只说对了一半。
Mythos 的意义不只是模型更强，而是它把“AI 挖洞”以一种接近工业化的形态摆到了行业面前：可以大规模运行，有可展示的真实结果，有可构造的 exploit，也有不能无约束释放的风险。它让大量原本旁观的公司、研究团队、开源组织和治理机构意识到：AI 挖洞不再是论文里的 demo，也不再是少数团队的工程探索，而是一个正在形成生产力的方向。
所以，Mythos 更像一次行业动员，而不是一个单纯的模型奇点。
这篇文章不想继续复盘 Mythos 本身，而是想讨论后 Mythos 时代会发生什么。我的核心判断是：发现漏洞的产能会继续上升，低垂和中垂果实会被快速消耗；之后，行业瓶颈会从“能不能发现”转向“能不能扫干净、能不能低噪声验证、能不能完成修复和治理”。
换句话说，发现正在变便宜，治理正在变稀缺。
引子：Mythos 不是奇点，而是行业动员信号
出圈来自能力、规模和叙事的组合
Mythos 的火爆，不能只从模型能力解释。
Anthropic 做对了几件事。第一，大规模运行，拿出了足够有冲击力的真实结果；第二，把漏洞发现、exploit 构造、防御协作和风险控制放进同一个叙事；第三，通过 Project Glasswing 把能力释放与受控交付绑定起来，让这件事不只是一个模型发布，而是一个行业事件。
这很关键。
如果只是某个团队说“我们的模型在某个 benchmark 上提升了 15%”，它很难真正改变行业投入。但如果一个模型被官方描述为能够在主流操作系统、浏览器、基础软件中发现多年未被发现的问题，能够协助构造 exploit，同时又危险到不能直接公开，那么它就不再只是一个技术成果，而会变成一个行业共同焦虑。
Mythos 的影响力来自这种组合：能力展示、规模运行、风险叙事和生态动员。
Mythos 改变的是行业投入的斜率
自动化漏洞挖掘并不是在 Mythos 之后才出现。早在此之前，就已经有少数团队在做 LLM 辅助审计、智能体安全审计、自动验证和大规模仓库扫描。我们自己也是比较早深入做这个方向的团队之一。
但在 Mythos 之前，这件事更多还是少数团队的探索。外部世界对它的理解往往停留在“AI 能不能发现一个漏洞”“LLM 会不会写 PoC”“benchmark 分数有没有提升”这些局部问题上。
Mythos 至少显著放大了行业对这一方向的关注和投入预期。
当一个头部模型公司把自动化漏洞挖掘包装成一个足够完整的产业故事后，更多公司开始投入，更多评测开始出现，更多开源项目被扫描，更多安全团队开始搭建自己的安全审计智能体。于是能力提升不再只来自单个模型，而来自整个系统的加速：模型、harness、任务编排、验证、补丁生成和披露流程，开始作为一个整体一起进化。
所以，哪怕没有 Mythos，如果 Anthropic 用另一个足够强的 Claude 版本大规模跑漏洞挖掘任务，并配合类似的叙事和生态动员，这个方向大概率也会沿着相近路径前进。
Mythos 的特殊之处在于，它把这条时间线压缩了。
它让行业从“这件事可能会发生”，直接进入“这件事已经发生，我们必须应对”。
真正加速的是模型与系统共同进化
讨论 AI 漏洞挖掘时，很多人容易把注意力全部放在模型上。但真正决定系统效果的，往往不是模型一个变量。
模型当然重要。更强的代码理解、漏洞假设生成、攻击路径推理、语义建模和 PoC 草案生成能力，都会直接提升系统上限。Mythos 在更难漏洞、更复杂 exploit 链和更长任务跨度上的进步，确实值得重视。
但工具调用稳定性、运行环境构建、动态验证、证据记录、状态管理、去重和修复链路，不是单纯的模型能力，而是整个系统工程的一部分。
这里需要把边界说清楚：
- Model：负责漏洞假设、安全语义、入口理解、数据流和状态推理、攻击路径构造、PoC 草案。
- Harness：负责构建、运行、隔离、插桩、观测、日志、崩溃采集和触发路径复现。
- Orchestrator：负责搜索策略、状态管理、预算分配、路径优先级、去重和多轮验证。
- Validator：负责反证候选，要求可达性、攻击者控制、信任边界跨越和影响证据。
- Governance：负责让确认问题进入修复、披露、发布和下游通知流程。
入口定位、数据流追踪、状态机理解、攻击路径推理，本质上主要是模型和安全建模能力。构建项目、跑测试、插桩、采集 trace、隔离危险行为、复现触发路径，则是 harness 和工具链能力。多轮搜索、候选去重、预算调度、失败重试、证据合并，更像编排能力。验证、定级、补丁、回归和披露，又属于后续治理链路。
把这些东西混在一起，容易误判这个方向的真正难点。模型提高了上限，但 harness、编排和验证决定这个上限能不能在真实仓库中稳定兑现。
趋势一：中垂果实会被快速释放
高价值软件会出现库存释放窗口
未来一到两年，我认为高价值基础软件可能会出现一轮阶段性的“库存释放期”。
这里说的不是最浅的低垂果实，也不是需要全新漏洞理论的顶级难题，而是过去因为人力、时间、覆盖和验证成本不足而沉积下来的中间层问题。
这类问题包括跨模块授权错配、parser 状态机边界、配置与权限组合、协议状态转换、传统 fuzzing 难触发但可以由语义搜索定位的问题。它们不一定需要突破性研究，但需要足够系统的代码理解、攻击面枚举、路径探索和验证能力。
过去这些问题之所以沉积下来，不是因为它们完全不可发现，而是因为发现成本太高。人工审计需要专家长时间投入，传统工具缺乏足够语义，验证和复现又很消耗人。AI agent 把这几个成本同时往下压，结果就是：以前需要安全研究员花几天甚至几周才能摸清的路径，现在可以被系统批量探索、筛选和验证。
操作系统内核、浏览器、加密库、媒体解析库、数据库、虚拟化组件、服务端框架等高价值软件类型，本来就是安全研究的重点目标。过去它们已经经历了多年人工审计、fuzzing 和静态分析，但 AI agent 带来了新的搜索策略和更便宜的验证成本。
如果 Linux 这类知名老仓库短期内出现阶段性漏洞井喷，并不奇怪。那未必说明这些项目突然变差，更可能说明过去多年沉积的风险被新工具集中释放。
这波释放不会无限持续
但这波释放不会无限持续。
当高价值老仓库被大量 AI 系统反复扫描之后，容易发现的问题会逐渐减少。过去沉积的漏洞库存会被消耗，新增漏洞也会更早被开发流程中的安全系统拦截。
这并不意味着这些项目会变得绝对安全，而是意味着漏洞发现的边际成本会重新上升。
早期，一个相对成熟的系统可能通过系统化扫描快速发现大量问题；后期，要找到新的高价值漏洞，就需要更强模型、更深领域知识、更复杂环境、更长搜索时间，或者更好的 exploit 构造能力。
自动化漏洞挖掘不会消除安全研究的难度。它会先消耗掉那些过去因为缺少规模化审计而存在的问题，然后把竞争推向更难的区域。
后续竞争会转向长尾仓库和单位资源效率
当头部项目的中等难度漏洞逐渐减少后，竞争会转向三个方向。
第一，谁能以更低成本扫更多二线仓库和长尾项目。大量真实风险并不只存在于头部基础软件中，也存在于无数使用广泛但维护资源不足的项目里。
第二，谁能发现更高复杂度、更依赖领域知识和跨模块理解的漏洞。这类漏洞不一定能靠简单模式匹配或单轮审计发现，需要 agent 更好地理解系统语义。
第三，谁能把漏洞发现能力嵌入开发流程，在漏洞进入 release 之前就内部消化掉。
这意味着漏洞挖掘会越来越像资源和效率的竞争。不是谁偶然发现一个洞，而是谁能用单位算力、单位时间、单位人工成本发现更多真实、重要、可修复的问题。
趋势二：竞争重心从“挖到洞”转向“扫干净”
挖到一个洞不能代表扫过一个仓库
从外部看，AI 挖洞像是一件很神奇的事：给模型一个仓库，模型读代码，然后发现一个高危漏洞。
但真正做过自动化漏洞挖掘的人都知道，挖到一个洞并不是最难的。尤其是在足够大的代码库、足够长的运行时间、足够多的尝试次数下，发现一些真实漏洞并不罕见。
很多项目本来就没有被系统审计过，攻击面长期沉积在那里。过去缺少的不是漏洞，而是足够便宜、足够自动化、足够持续的探索方式。
因此，用“是否发现了一个漏洞”来评价 AI 漏洞挖掘系统，很容易高估系统能力。一个系统可能偶然撞到真实问题，却无法说明它理解了整个仓库的安全边界；也可能在某个模块表现很好，却完全漏掉更关键的攻击面。
真正难的是：能不能把一个仓库扫得相对干净。
覆盖能力来自安全建模、编排和可观测性
严格来说，在真实仓库里很难精确衡量“召回率”，因为我们通常没有完整 ground truth。更现实的指标，是系统能否建立足够好的覆盖能力：主要攻击面有没有被枚举，关键入口有没有被跑到，重要信任边界有没有被建模，候选路径有没有证据支撑。
一个可用的漏洞挖掘系统，不能只在某个模块里撞到几个漏洞，就宣称完成了安全审计。它必须系统性理解仓库结构、攻击面、信任边界、权限模型、危险 API、历史漏洞模式，并根据这些信息安排探索顺序。
哪些目录值得看？哪些入口值得跑？哪些数据流值得追？哪些权限边界最容易出错？哪些模块虽然代码少，但一旦出问题影响很大？这些判断更多属于模型和安全建模能力。
但判断之后，还需要编排和可观测性来兑现。
编排决定任务如何拆分、哪些路径优先验证、预算如何分配、哪些候选需要二次审查。harness 和工具链决定项目能否构建、测试能否运行、覆盖率和日志能否被观察、fuzzing 或静态分析结果能否被纳入证据链。
真正可复盘的仓库级扫描，需要留下覆盖证据：
- 攻击面 inventory：入口、权限边界、危险 API、协议状态、文件、网络、IPC 和插件扩展点。
- 覆盖 receipt：哪些路径被看过，哪些工具跑过，哪些模块实际执行过，哪些路径只被静态分析过。
- 候选账本：候选来源、去重结果、验证失败原因、未验证路径和剩余风险。
- 预算记录：时间花在哪里，为什么优先这些路径，哪些高风险区域需要下一轮。
这也是为什么很多系统可以找到漏洞，却很难做到“扫干净”。真正的覆盖能力来自模型、安全建模、编排、工具和运行环境的共同作用，而不是某一个单点组件。
高覆盖和低噪声天然拉扯
做到高覆盖和低噪声并不容易。
高覆盖要求系统尽可能覆盖更多攻击面，低噪声要求系统尽可能少打扰维护者。这两个目标天然有张力。探索越广，候选越多；候选越多，验证成本越高；验证越严格，吞吐量又会下降。
因此，自动化漏洞挖掘真正难的地方，不是让模型说出“这里可能有问题”，而是让整个系统完成一个闭环：发现候选点，理解安全语义，构造攻击假设，验证可利用性，去重，判断影响，生成报告，辅助修复。
即使发展到今天，真正能同时兼顾较高覆盖和较低噪声的团队仍然是少数。
这也是我对当前阶段的基本判断：对于可构建、可验证、攻击面相对清晰的仓库，低垂和中等难度的漏洞并不神秘。真正稀缺的，是把它们稳定、成批、低噪声地扫出来的系统能力。
趋势三：系统能力会比单次模型表现更重要
模型决定上限，系统决定上限能否兑现
Mythos 的确把更高处的一些果实变得更容易触达，但它没有把问题变成无限简单。更难的漏洞仍然需要更强模型、更好的 harness、更专业的领域知识，以及更长时间的搜索和验证。
虽然 harness 和编排非常重要，但这并不意味着模型能力不重要。
恰恰相反，当低垂和中等难度的漏洞被快速收割后，模型能力会变得更重要。更高处的漏洞往往需要更长程的代码理解、更复杂的状态推理、更精细的协议和业务语义建模、更强的 exploit 构造策略，以及更稳定的多轮任务执行。它们不是简单地“多跑几遍”就一定能找到。
但真实世界的仓库不会因为模型更强就自动变得可审计。它们有构建问题、依赖问题、环境问题、平台差异、测试缺口、权限边界、运行时状态和大量噪音。
所以，后 Mythos 时代的主战场不会是单次模型 benchmark，而是 model + harness + orchestrator + validator 的整体系统效率。
同样的模型，不同系统会跑出完全不同的结果
同样一个模型，放在不同系统里，产出会差很多。
一个系统可能只会让模型读代码、输出候选报告；另一个系统则能构建目标、执行测试、插桩关键路径、调用静态分析和 fuzzing，把候选放进多轮验证流程，并在失败后调整搜索策略。
前者更像“会写安全评论的模型”，后者才接近“能工作的自动化审计系统”。
系统能力至少体现在几件事上：
- 是否能稳定构建和运行目标项目。
- 是否能把模型假设转化为可执行验证任务。
- 是否能记录失败路径，而不是每轮都从头开始。
- 是否能合并重复候选，避免把同一个问题报十遍。
- 是否能反证候选，而不是只收集支持漏洞成立的证据。
- 是否能把确认问题交给补丁、测试和披露流程。
这些能力并不总是出现在论文指标里，但它们决定系统能不能在真实仓库中长期运转。
自动化漏洞挖掘会越来越工程化
未来，自动化漏洞挖掘会越来越像一个工程系统，而不只是一个模型能力展示。
它会有任务队列、预算调度、覆盖记录、候选账本、验证流水线、回归测试、报告模板、补丁生成、维护者协作界面和披露状态机。
这件事听起来没有“模型自己发现 0day”那么戏剧化，但它才是这个方向真正生产化的形态。
Mythos 让行业看到了上限，接下来决定差距的，是谁能把上限稳定兑现为低噪声、高覆盖、可治理的产出。
趋势四：误报治理会成为核心壁垒
候选点不是漏洞报告
AI 很容易提出“看起来像漏洞”的候选点。它可以指出某个输入没有校验，某个路径可能越权，某个序列化逻辑可能危险，某个边界检查可能不完整。
但从候选点到可信报告，中间还隔着很长一段路。
这个候选点是否可达？攻击者是否能控制输入？是否跨越了真实信任边界？是否需要不现实的前置条件？是否已经被上游逻辑过滤？是否只是一个代码味道，而不是安全问题？这些问题不解决，报告就很难被维护者接受。
如果候选直接进入维护者 inbox，AI 带来的就不是防御增益，而是治理负债。
证据链要证明可达、可控、可影响
PoC 是强证据，但不是所有漏洞都适合或需要完整 PoC。很多结论需要靠可达性分析、攻击者控制证明、信任边界跨越、sanitizer trace、crash 复现、最小触发测试、配置前提和代码审查共同确认。
所以，真正可用的系统必须构建验证证据链。
一份合格报告至少应该回答：
- 攻击者具备什么能力？
- 输入从哪里进入，能否被攻击者控制？
- 可达路径是什么？
- 跨越了哪条信任边界？
- 影响落在哪个 sink 或安全属性上？
- 复现 artifact 是什么？
- 修复和回归测试如何证明风险下降？
没有验证，系统输出的是安全噪音；有了证据链，候选点才可能变成可以被维护者处理的漏洞报告。
验证和修复需要分开看
漏洞验证阶段要证明可达性、触发条件和影响。修复阶段才是生成补丁、回归测试，并通过测试和审查降低复发风险。
把这两个阶段混在一起，会让系统看起来闭环，实际上每一环都不够扎实。
一个系统能写补丁，不代表它已经证明漏洞成立；一个系统能证明漏洞成立，也不代表它能生成可合并、低回归风险的补丁。验证系统、修复系统和披露系统应该互相衔接，但不能互相替代。
后 Mythos 时代，误报治理会成为真正的核心壁垒。能同时做到“覆盖足够广”和“证据足够硬”的系统，才会被维护者、安全团队和企业开发流程真正接住。
趋势五：瓶颈会从发现端转向治理端
候选发现之后，还有更长的治理链条
过去，漏洞挖掘的瓶颈主要在发现端。
高水平安全研究员少，能长期审计复杂代码库的人更少。很多开源项目多年没有接受过系统安全审计，漏洞自然长期沉积。谁能更早发现这些漏洞，谁就掌握主动权。
但随着发现端产能上升，真正的问题会变成：这些候选问题谁来确认？谁来修？谁来合并？谁来发布？谁来通知下游？谁来处理重复报告、低质量报告和争议报告？
这里需要把链条拆清楚：
- 候选发现：系统提出可能存在安全问题的点。
- Intake / 去重 / 分流：合并重复报告，过滤明显噪音，分配优先级。
- 验证 / 定级：确认可达性、影响、前置条件和风险等级。
- 修复 / 测试 / 回归：生成补丁，跑测试，review，合并。
- 披露 / 发布 / 下游通知：协调 CVE、embargo、公告、版本发布和依赖方通知。
发现能力提高后，后面几步都会成为新的拥塞点。
一个没有被验证的漏洞候选，只是候选信号；一个没有被修复的确认漏洞，只是风险库存；一个没有被合并和发布的补丁，也没有真正保护用户。
确认、修复和披露会成为新的主战场
未来衡量 AI 漏洞挖掘系统，不能只看它发现了多少问题，还要看它有多少问题被确认、被修复、被合并、被发布，以及从发现到修复的时间被压缩了多少。
这也是为什么 OpenAI 的 Patch the Planet、Google DeepMind 的 CodeMender 以及 Anthropic 的 Project Glasswing 都不只停留在“发现漏洞”叙事上，而是强调验证、修复、协作或受控交付。
行业已经意识到：只提高发现能力是不够的，防御收益发生在漏洞被消化之后。
开源生态会最先感受到这种压力。
很多关键项目并没有专职安全团队，维护者本来就已经被 issue、PR、release、兼容性和用户支持压得很重。当 AI 让漏洞报告数量暴涨，如果没有对应的验证、去重和补丁能力，维护者收到的不是帮助，而是负担。
更麻烦的是，AI 时代的漏洞报告质量会高度分化。一部分报告可能非常完整，包含复现步骤、影响分析、补丁和测试；另一部分报告则可能只是模型根据代码片段生成的低质量猜测。维护者必须在这些报告之间做判断，而这本身就是成本。
如果治理体系不升级，AI 挖洞能力越强，维护者 inbox 里的噪音也可能越多。真正高质量的漏洞，反而可能被低质量报告淹没。
披露流程会从自然语言报告变成安全工单
现有漏洞披露流程是为低吞吐时代设计的。
一个研究员发现一个漏洞，写报告，联系厂商，等待确认，协调 CVE，发布补丁。这套流程在人工时代可以运转，因为漏洞报告的数量相对有限。
但 AI 时代不一样。
当一个系统可以一天生成几十、几百甚至更多候选报告时，传统流程会被压垮。更麻烦的是，其中既有真实高危漏洞，也有低质量 AI slop，还有重复报告、半验证报告、夸大影响报告和缺少补丁的报告。
如果仍然沿用过去的披露流程，维护者会被迫把大量时间花在判断报告质量上，而不是修复真正重要的问题。
未来的漏洞报告更像安全工单，而不是一篇自然语言说明。它应该包含受影响版本、入口、攻击者能力、可达路径、跨越的边界、影响、复现 artifact、建议修复、回归测试和披露状态。
项目方也需要新的入口机制。不是所有报告都直接进入维护者 inbox，而是先经过自动分流、去重、验证和优先级排序。对于缺少复现步骤、缺少影响证明、缺少版本信息的报告，系统可以先要求补充材料；对于重复报告，系统可以自动合并；对于高置信高影响报告，系统可以优先通知核心维护者。
这是一个很反直觉的结论：AI 提高了发现漏洞的能力，但如果治理体系不升级，它也可能降低整个生态修复漏洞的效率。
趋势六：漏洞挖掘会前移到 CI/CD 和发布流程
安全 agent 会先进入成熟团队的 CI/CD
在安全成熟度较高的软件团队中，安全 agent 进入 CI/CD 很可能成为重要方向。
既然 AI agent 可以理解代码变更、构造攻击路径、生成验证思路和补丁草案，那么它就不应该只作为外部扫描器存在，而应该成为开发流程的一部分。
未来成熟的软件团队可能会在代码合并前、release 前、依赖升级前自动运行安全 agent。它不只是检查格式、跑测试、做静态扫描，而是尝试理解这次变更是否引入新的攻击面，是否改变权限边界，是否让原本不可达的危险路径变得可达。
它也不需要每次都全仓重扫。更现实的形态，是围绕具体变更做 diff-scoped threat model：这次变更新增了哪些入口、权限、依赖、构建步骤和 release gate；哪些安全边界受影响；哪些路径需要深扫；哪些候选需要在沙箱里复现。
当这个流程成熟后，很多漏洞会在进入公开版本之前就被发现并修复。
发布后外部发现的占比可能下降，但 CVE 总量未必下降
如果漏洞挖掘系统真正进入软件生产线，高成熟度项目中“发布后才由外部发现并推动披露”的漏洞占比，长期可能下降。
原因不是漏洞不存在了，而是更多漏洞会在 release 前被内部发现、内部验证、内部修复。过去需要外部研究员发现并披露的问题，未来可能在 PR 阶段就被 agent 拦下。
这会改变漏洞生命周期。
漏洞从“发布后被发现”变成“合并前被发现”，从“外部披露驱动修复”变成“内部质量流程驱动修复”，从“CVE 事件”变成“开发流程中的一个安全检查失败”。
但这不等于全行业 CVE 总量一定下降。短期内，AI 可能同时提高发现能力和申报能力，让公开披露数量先上升。长期看，头部项目和长尾项目也会分化：成熟项目更早内部消化，长尾项目继续暴露大量未治理风险。
软件数量增长会拉长这个过程
这个过程不会很快。
原因很简单：软件数量也在井喷。AI 让写代码变得更便宜，开源项目、内部项目、自动生成代码、一次性服务和 AI agent 生成的 glue code 都会变多。大量项目不会立刻接入高质量安全扫描，也没有足够资源处理扫描结果。
因此，我们可能会同时看到两个现象：头部项目越来越早地在内部发现并修复漏洞；长尾项目则继续暴露大量未治理风险。
自动化漏洞挖掘不会让漏洞消失，它会改变漏洞被发现、被修复、被披露和被利用的时间顺序。
当漏洞挖掘进入 CI/CD 后，安全竞争会前移。过去，很多安全竞争发生在 release 之后：攻击者、研究员和防御者围绕已经发布的软件展开竞速。未来，这个竞争会越来越多发生在 release 之前。
谁能在代码合并前发现问题，谁就能减少后续披露和修复成本；谁能在依赖升级前识别供应链风险，谁就能避免引入新的攻击面；谁能在 agent 生成代码时同步做安全验证，谁就能减少 AI 生成代码带来的新风险。
安全不再只是发布后的补救动作，而会越来越像软件生产线里的质量控制环节。
趋势七：当洞更难挖，攻击者会转向变更入口
某些场景下，投毒会比继续挖高难度 0day 更有性价比
还有一个趋势值得警惕：当漏洞越来越难挖之后，攻击者可能会转向投毒和供应链操纵。
如果头部项目持续被 AI agent 扫描，低垂和中等难度漏洞逐渐减少，那么纯粹靠挖 0day 的成本会重新上升。在某些目标和攻击者模型下，另一条路径可能更经济：不是寻找已有漏洞，而是让未来版本主动带入可利用的问题。
这并不是一个全新的攻击思路，但 AI 会改变它的成本结构。
攻击者可以用 AI 寻找更适合投毒的项目、更容易被接受的 PR、更隐蔽的代码改动、更合理的伪装理由，以及更难被传统扫描发现的后门逻辑。
当自然漏洞库存被消耗，攻防竞争会从“寻找既有 bug”，部分转向“控制变更入口”。
供应链攻击不全是造洞，但都会绕开传统挖洞成本
这里需要区分两类问题。
一类是植入型漏洞或后门。攻击者通过看似正常的修复、重构、性能优化或兼容性改动，在项目中留下未来可利用的路径。
另一类是供应链分发链路攻击，包括恶意依赖、typosquatting、维护者账号攻击、构建脚本投毒、发布流程劫持、依赖推荐污染等。它们不一定是在代码中“造洞”，但都可以绕开传统挖 0day 的成本，直接攻击软件进入用户环境的路径。
传统漏洞挖掘更多关注代码中的 bug，而供应链攻击往往关注流程、身份、信任和分发链路。
因此，未来的安全系统不能只看代码本身，也要看代码是如何进入项目、如何被构建、如何被发布、如何被下游消费的。
安全系统要识别异常信号，而不是声称读懂意图
AI 编程工具普及后，AI 生成 PR 和 AI 推荐依赖也会引入新的风险。
攻击者可能通过看似正常的修复、重构、性能优化或兼容性改动隐藏恶意逻辑。也可能通过污染文档、issue、依赖生态和包名空间，影响 AI 工具的建议，让开发者无意中引入危险代码或依赖。
这类问题的难点在于，它们不一定像传统漏洞那样有清晰的输入源、危险操作和可利用路径。它们可能更像上下文不一致：代码在功能上看似合理，但引入了不必要的权限、异常的网络访问、可疑的构建行为，或在测试覆盖之外改变了关键安全属性。
未来的安全系统不仅要识别 bug，也要识别不符合上下文的行为和能力增量。
它要判断一个改动是否符合项目上下文，是否引入不必要的权限，是否访问了异常资源，是否修改了构建或发布链路，是否在测试覆盖之外改变了关键行为，是否来自可信的提交者和分发路径。
这比传统漏洞扫描更难。
因为 bug 通常可以通过程序行为证明，而恶意意图很难被系统直接“读懂”。更稳妥的做法，是通过可观察信号间接推断风险：异常权限、异常依赖、异常数据流、异常构建步骤、异常发布链路、异常维护者行为、缺失 provenance、签名或构建证明。
后 Mythos 时代，攻防双方都会使用 AI。防御方用 AI 找洞、修洞，攻击方也会用 AI 寻找更隐蔽、更经济的攻击路径。漏洞挖掘能力的提升，不会终结攻防对抗，只会改变对抗的形态。
结语：主战场是消化发现
回顾过去几年，AI 自动化漏洞挖掘经历了几次范式变化。
最早是把模型当分类器，判断一段代码有没有漏洞。后来是让 LLM 辅助 fuzzing、静态分析、规则生成。再后来是 agentic 审计，模型可以主动读代码、调用工具、形成假设并验证。
Mythos 之后，我们进入了新的阶段。
这个阶段的核心问题不再是“AI 能不能挖漏洞”。答案已经很清楚：能，而且会越来越强。
真正的问题变成：系统能否覆盖主要攻击面，过滤噪音，完成验证和修复，并被维护者实际接住。
发现候选点只是第一步。系统还需要理解安全语义、证明可利用性、判断影响范围、生成高质量报告、给出修复方案、帮助维护者合并补丁，并把这些能力接入真实开发流程。
这要求团队同时具备模型能力、harness 工程、安全研究能力、产品化能力和生态协作能力。
单纯会调模型不够，单纯会跑工具也不够。未来领先的系统，一定是把模型推理、工具执行、环境构建、动态验证、补丁生成和治理流程连接在一起的系统。
后 Mythos 时代，漏洞挖掘的主战场不再只是发现，而是消化发现。
主动权会属于能把扫描结果接进修复链路的人：验证、补丁、合并、发布，少掉任何一环，发现能力都会折损成噪音。
Mythos 让行业意识到自动化漏洞挖掘的上限比过去想象得更高。但接下来真正决定行业走向的，不只是模型能不能继续变强，而是整个漏洞治理体系能不能跟上发现能力的增长。
如果说 Mythos Moment 是一次动员，那么后 Mythos 时代的核心任务，就是把这次动员带来的漏洞发现产能，转化为真实、可持续、可治理的防御能力。