AI辅助漏洞挖掘：能力边界、风险与防御实践

一、为什么需要重新审视漏洞挖掘

大型操作系统内核、浏览器和基础软件的代码量以千万行计，人工审计只能覆盖其中一小部分。过去二十年，模糊测试、静态分析和符号执行已经成为主流手段，但它们各有盲区。模糊测试依赖输入覆盖率，静态分析容易产生大量误报，符号执行在路径爆炸面前很难扩展。

大语言模型带来的变化主要体现在语义层面。模型可以阅读函数之间的调用关系，理解注释与实现是否一致，并对可疑的边界检查、内存生命周期或权限判断提出假设。这些假设本身不是结论，但能显著缩小人工复核的范围。因此，AI辅助漏洞挖掘更适合被理解为一种“候选点生成器”，而不是“自动裁决者”。

二、典型工作流

一套可落地的流程通常包含以下六个环节。

1. 资产梳理：确定待评估的代码库、版本、依赖与构建配置，明确哪些模块属于攻击面。
2. 候选点生成：由模型结合代码结构、历史缺陷模式和已知漏洞类型，列出可疑位置。
3. 语义推理：针对每个候选点，模型解释数据流与控制流，给出触发条件的假设。
4. 动态验证：在隔离环境中构造测试用例或测试工具，观察程序是否真的出现异常。
5. 去重与分级：合并同一根因的多个候选，按影响范围、可利用条件和修复难度排序。
6. 补丁与回归：由工程师编写修复，并运行原有测试集与针对性回归测试。

关键在于第四步。没有动态验证的模型输出，只能算一条待查线索。

三、能力边界：模型输出不能直接当结论

使用这类工具时，需要正视以下限制。

• 幻觉：模型可能描述一个代码中并不存在的分支，或者误读宏定义和条件编译。
• 上下文限制：大型项目的跨文件依赖超出单次输入的范围，遗漏是常态。
• 环境依赖：许多缺陷只在特定编译选项、硬件或并发时序下出现，单纯阅读代码无法判断。
• 误报与漏报：模型对明显模式敏感，对新型或组合型缺陷的覆盖不稳定。

评估这类工具时，建议采用以下指标，而不是只看发现数量。

指标	含义	关注点
精确率	报告中真实缺陷的比例	降低人工复核成本
召回率	已知缺陷中被找到的比例	需要用已知样本集测量
复现成功率	候选点能被动态验证的比例	直接反映证据质量
修复回归率	补丁引入新问题的比例	反映补丁质量

数量本身没有意义。一百条无法复现的候选，价值远低于十条附带完整证据的缺陷。

四、关键基础设施场景的特殊要求

电力、水务、轨道交通等工业控制系统对可用性要求极高，评估活动必须遵循更严格的约束。

• 测试只在仿真或数字孪生环境中进行，不接触生产网络与现场设备。
• 对保护逻辑、定值与控制指令相关的代码，任何修改都需要双人复核和书面授权。
• 评估产出的材料应按敏感级别管理，不随意共享给未授权人员。
• 工控协议与专有通信的测试，需要提前与设备供应方确认责任边界。

在这类场景中，安全团队的首要目标是验证防护措施是否有效，而不是证明某种攻击能否成功。

五、隔离与权限控制

动态验证需要运行不可信或高风险代码，因此隔离是前提。常见做法包括以下几点。

• 使用虚拟化或微虚拟机作为执行边界，每次测试从干净快照启动，结束后整体销毁。
• 评估网络与生产环境物理或逻辑隔离，禁止评估环境直接访问外部网络。
• 为评估账户分配最小权限，禁止持有宿主机的管理员凭据。
• 记录每次运行的输入、模型版本、环境配置和输出，保证结果可追溯。
• 将模型服务与代码仓库的访问权限分开管理，防止未经审批的源代码外发。

下面的示例展示如何用数据结构约束缺陷记录的状态流转。只有附带证据并经人工审核的记录，才能进入“已复现”状态。

from dataclasses import dataclass, field
from enum import Enum
class Status(Enum):
    CANDIDATE = "candidate"    # 模型给出的候选点
    REPRODUCED = "reproduced"  # 已有可复现证据并通过审核
    PATCHED = "patched"        # 修复已提交并通过回归
    REJECTED = "rejected"      # 证据不足或确认为误报
@dataclass
class Finding:
    finding_id: str
    component: str
    description: str
    status: Status = Status.CANDIDATE
    evidence: list[str] = field(default_factory=list)
    reviewer: str | None = None
    def promote(self, evidence_ref: str, reviewer: str) -> None:
        """将候选点推进到已复现状态，必须同时提供证据与审核人。"""
        if not evidence_ref:
            raise ValueError("缺少可复现证据，不能进入已复现状态")
        if not reviewer:
            raise ValueError("必须指定人工审核人")
        self.evidence.append(evidence_ref)
        self.reviewer = reviewer
        self.status = Status.REPRODUCED

这段代码的作用在于把流程规则写进系统，避免有人跳过验证直接上报。

六、结果验证与补丁审核

模型生成的补丁草稿同样需要严格审查。建议按以下顺序执行。

1. 确认补丁对应的根因，而不是只让崩溃消失。
2. 检查补丁是否最小化，避免顺带修改无关逻辑。
3. 运行原有测试套件，并补充针对该缺陷的回归用例。
4. 对修改的函数重新执行模糊测试，观察是否出现新的异常。
5. 评估性能影响，尤其是在热路径上增加的检查。
6. 由熟悉该模块的工程师完成代码审查。

补丁被合入之前，任何一步失败都应退回重新分析。

七、落地建议

对于希望引入此类能力的团队，可以分三步推进。

• 第一步，建立基准：收集本组织历史上已确认的缺陷样本，用它们测量工具的召回率和误报率。没有基准，就无法判断工具是否有用。
• 第二步，小范围试点：选择一两个非关键模块，在隔离环境中跑完整流程，记录人工复核耗时与产出质量。
• 第三步，制度化：明确授权范围、审批人、数据分级规则和漏洞披露流程，并把模型版本与提示模板纳入变更管理。

八、常见误区

• 把数量当成效果：候选点越多，复核负担越重。应关注复现成功率和最终修复数量。
• 把模型自评当验证：模型认为“这段代码有问题”并不等于问题存在。
• 忽视数据边界：未经审批将内部源代码发送到外部服务，本身就是安全事件。
• 跳过回归测试：补丁修复了一处缺陷，却可能破坏已有行为，必须依靠测试兜底。

AI辅助漏洞挖掘可以提高候选点的产出效率，但判断权仍在工程团队手中。团队应当先建立验证机制，再考虑扩大使用范围。