一、从“辅助编程”到“自动化漏洞发现”：一个信号正在出现

过去一段时间，大模型在研发流程中的角色更多集中在代码生成、补全、解释和单测编写。但近期围绕“模型驱动漏洞挖掘”的公开讨论，释放了另一个信号：前沿模型正在从“辅助写代码”走向“辅助发现并验证漏洞”。

有公开讨论提到，某前沿模型团队以约百万美元级成本扫描某操作系统内核，并验证了数百个漏洞；折算下来，单个漏洞的验证成本被压缩到千美元量级。这个数字是否适用于所有场景仍需谨慎看待，因为不同代码库的复杂度、可达性、验证环境和人工复核成本差异很大。但它至少说明一件事：漏洞挖掘的边际成本结构正在变化。

传统漏洞挖掘高度依赖安全专家的经验、时间与工具链组合。静态分析、动态插桩、模糊测试、符号执行、差分测试等方法各有优势，也各有明显边界：要么误报高，要么覆盖有限，要么需要大量人工构造输入。前沿模型的价值不在于替代某一种方法，而在于它可以跨代码、文档、配置、调用链和测试用例进行语义关联，把“发现线索”和“构造验证”之间的距离缩短。

这意味着，未来安全团队之间的差距，可能不再只取决于“有没有扫描器”，而取决于“有没有可持续运行的模型审计与验证闭环”。

二、为什么模型能发现传统方法难捕捉的漏洞

模型擅长的并不是简单套用规则，而是理解多个系统层之间的交互。以原文提到的一类典型问题为例：某测试环境中的答题评分器使用数学表达式校验组件来验证答案是否正确。攻击输入并不是直接写入明显恶意代码，而是利用了多层机制的组合：

1. 输入校验只允许字母；
2. 攻击者使用“看起来像普通字母、实际为形近字符”的输入绕过检查；
3. 后续运行时又将这些形近字符规范化为真正字母；
4. 模型通过访问函数的文档字符串，按位置挑选字符，拼接出可执行片段；
5. 最终构造出一个表达式：先触发系统命令，再利用布尔短路返回合法数学答案。

用伪代码抽象，大致是：

最终结果 = 触发系统命令(标记) 或 合法数学答案

由于系统命令执行成功时返回的状态在布尔上下文中被视为假值，或运算会继续返回后面的合法数学答案。于是，评分器看到的是“答案正确”，但系统命令已经被执行。这个案例的关键不在于某个具体语言或库，而在于它同时涉及输入校验、字符规范化、文档字符串内容、表达式求值和布尔短路等多个环节。普通代码审查往往只盯住一个函数，普通模糊测试也很难生成这种“校验器语义”和“执行器语义”不一致的输入。

模型之所以可能发现这类问题，是因为它可以同时阅读校验逻辑、规范化逻辑、表达式求值逻辑和测试用例，并在语义层面提出假设：如果输入在校验前后发生形态变化，是否会出现“检查对象”和“执行对象”不一致？如果表达式求值允许访问对象属性或文档字符串，是否能拼接出可执行片段？这种跨层推理正是传统单点工具较难覆盖的部分。

当然，模型并不会天然具备这种能力。它需要足够的上下文、可执行的验证环境、清晰的权限边界，以及人工对结果的复核。否则，模型很容易产生“看似合理但不可利用”的误报。

三、漏洞挖掘的成本结构正在改变

原文中一个值得关注的判断是：漏洞挖掘可能从“能力比拼”部分转向“算力与模型能力比拼”。这个判断需要拆开看。

一方面，模型驱动审计确实会消耗算力。要让模型阅读大规模代码库、追踪调用链、构造验证用例、在沙箱中反复试错，需要计算资源、隔离环境和自动化编排。模型能力越强、上下文越长、验证闭环越完整，单位时间内能覆盖的代码面就越大。对于攻击方而言，这意味着发现漏洞的“搜索成本”可能下降；对于防守方而言，这意味着持续审计的“覆盖成本”可能下降。

另一方面，算力并不是全部。漏洞挖掘的效果还取决于数据质量、代码可达性、业务上下文、验证环境、误报过滤和修复优先级。一个模型即使能提出大量候选问题，如果无法判断哪些路径真实可达、哪些影响核心业务、哪些可以被外部触发，那么它带来的只是更多告警，而不是更强安全能力。

因此，更准确的说法是：模型把安全团队从“手工搜索为主”推向“模型搜索+人工验证+工程闭环”的模式。安全专家不会消失，但角色会迁移。重复性的模式匹配、初筛、样例构造会更多交给模型；专家则转向架构风险评估、漏洞可达性判断、利用链分析、修复方案设计和安全治理。

四、对攻击方的影响：窗口更短、路径更隐蔽

从攻击视角看，模型驱动的漏洞发现会带来两个直接变化。

第一，漏洞发现窗口可能缩短。攻击方可以用模型对公开代码、历史漏洞、配置文件和接口文档进行大规模关联分析，快速生成候选攻击面。过去需要数周人工审计才能发现的逻辑缺陷，可能在更短时间内被定位。尤其对于输入校验与执行语义不一致、权限判断顺序错误、序列化与反序列化边界不清等问题，模型具备较强的跨层推理潜力。

第二，攻击路径可能更隐蔽。模型可能发现“看起来不像漏洞”的组合问题，例如字符规范化差异、文档字符串泄露、表达式求值副作用、布尔短路副作用、错误处理路径中的权限绕过等。这类问题往往不满足传统规则，也不容易被单点扫描器覆盖。攻击方一旦掌握这种能力，防守方仅靠季度渗透和定期扫描会越来越被动。

但也要看到，攻击方同样受限于验证环境和权限边界。模型提出的假设需要在真实环境中验证，很多高危漏洞需要多步利用链和特定配置才能成立。因此，防守方并非无牌可打，关键是把审计频率和验证能力提上来。

五、对防守方的影响：从季度审计到持续审计

对防守方而言，模型驱动漏洞挖掘最重要的改变不是“多了一个工具”，而是“审计节奏”需要变化。

过去很多团队的安全审计是季度或版本级动作：上线前扫描、重大变更后渗透、出现事件后复盘。面对模型辅助的攻击方，这种节奏可能不够。更合理的做法是把模型审计嵌入研发流程：代码提交、合并请求、制品构建、配置变更和接口发布时，都能自动触发轻量级模型审查；对高风险模块再进行深度验证和人工复核。

防守方还应重视“验证闭环”。模型发现候选问题后，不能只停留在报告层面，而要在隔离环境中构造最小验证用例，确认是否可达、是否可触发、影响范围多大。只有完成验证，才能进入修复优先级排序。否则，模型只会制造更多噪声。

在基础设施层面，团队可以把模型审计、沙箱验证、日志审计、告警编排、制品扫描和修复回归串成闭环。百度智能云提供的通用计算、对象存储、日志与监控类产品可以承载其中部分基础设施，但核心仍然是流程、数据治理和权限隔离，而不是简单采购一个“模型扫描”能力。

六、企业落地路线：四层能力缺一不可

企业要应对模型时代的攻防变化，建议从四层能力入手。

第一层是模型驱动代码审查。不要只让模型“找漏洞”，而要给它明确任务：追踪不可信输入、检查校验前后语义一致性、分析表达式求值边界、检查权限判断顺序、识别危险函数调用链。任务越具体，误报越少。

第二层是动态验证与沙箱。模型提出的漏洞假设必须可验证。企业应建设隔离执行环境，限制网络、文件系统和系统命令权限，记录完整审计日志。对于表达式求值、模板渲染、反序列化、命令拼接等高风险场景，优先建立可复现的最小验证用例。

第三层是漏洞知识库与优先级。模型输出需要与资产重要性、暴露面、可达性、利用条件和历史漏洞数据结合。一个在内部测试环境中的低危问题，和一个可被公网触发的高危问题，修复优先级完全不同。企业应建立统一的漏洞数据模型，把模型发现、人工确认、修复状态和回归结果关联起来。

第四层是修复闭环与回归。模型审计不是一次性活动。修复后要自动回归验证，确认漏洞不可再触发，同时检查是否引入新的绕过路径。对于字符规范化、表达式求值、权限校验等易错点，应沉淀为团队规则和测试用例，纳入持续集成与交付流水线。

七、不能神化模型：误报、权限与可解释性仍是关键

模型驱动漏洞挖掘很有价值，但不能神化。首先，模型可能产生误报，把不可达路径、测试代码或无效配置当成真实漏洞。其次，模型可能遗漏需要复杂业务上下文才能理解的问题。第三，模型审计涉及代码和日志等敏感数据，必须做好权限隔离、数据脱敏和审计留痕。第四，模型输出需要可解释性，安全团队要知道它为什么认为某条路径可达、某个输入可触发、某个修复方案有效。

因此，更稳妥的定位是：模型是高效的“侦察兵”和“验证助手”，不是最终决策者。人仍然负责授权、风险评估、修复取舍和合规判断。企业需要建立模型审计的评测集和回归机制，用历史漏洞、已知绕过案例和业务场景持续校准模型效果。

八、结语

前沿模型协助发现数百高危漏洞的讨论，真正值得关注的不是某一个具体案例，而是它揭示了攻防节奏的变化：漏洞发现正在从“人工经验驱动”转向“模型搜索+工程验证+专家决策”的组合模式。攻击方会获得更快的发现能力，防守方也会获得更持续的审计窗口。最终拉开差距的，不只是算力，而是谁能把模型能力、验证环境、漏洞数据和修复闭环真正组织起来。

如果没有可用的前沿模型能力，团队可能在发现速度上落后；但如果只有模型而没有验证和治理，团队只会被更多告警淹没。模型时代的网络安全，不是让攻防双方简单派出 AI “肉搏”，而是把安全工程从周期性检查升级为持续运行的系统能力。