AI辅助漏洞挖掘实践：如何科学评估审计模型

一、发现数量为什么不能直接代表能力

安全审计的产出通常以”发现了多少问题”计量。这个数字看起来直观，却受到很多因素干扰。扫描范围越大，结果越多。判定阈值放宽，误报随之增加。同一个缺陷若在多个文件、多次运行中重复出现，计数又会被放大。因此，只比较数量的结论往往不成立。

评估一个模型或一套审计流程，至少要回答三个问题：报告的问题中有多少是真实存在的；真实存在的问题中找到了多少；找到的问题能否被稳定复现。对应的指标如下。

• 精确率：有效发现数占全部报告数的比例，即 TP /（TP + FP）。
• 召回率：已找到的已知缺陷占全部已知缺陷的比例，即 TP /（TP + FN）。
• 稳定性：相同输入多次运行，结果的重合程度。
• 严重性分布：高危与低危问题的比例。在多数场景下，这比总数更能说明价值。

二、评测流水线的基本结构

一条可复现的评测流水线通常包含七个环节：样本准备、上下文构建、模型审计、结果归一化、去重、人工复核和指标统计。每个环节都要记录输入、输出和版本号，便于回溯。

下面是一段示意伪代码，用于说明各环节的衔接关系：

function evaluate_audit_pipeline(model, benchmark, runs):
    results = []
    for run in 1..runs:
        for case in benchmark:
            context = build_context(case.files, budget=case.token_budget)
            raw_findings = model.audit(context, prompt_template)
            normalized = normalize(raw_findings)
            results.append(match_against_labels(normalized, case.labels))
    return aggregate(results)   # 精确率、召回率、运行间方差

上下文构建决定模型能看到什么。如果只提供单个文件，跨文件的数据流漏洞将无法被发现。如果上下文超出预算，关键代码可能被截断。因此，构建阶段需要明确记录喂给模型的文件范围和截断策略。

归一化负责把不同模型的输出统一为相同结构，包括文件路径、位置、缺陷类别和严重等级。输出格式不统一时，后续的去重和比对都无法可靠进行。

三、基准集设计

基准集决定了评测结论的可信度。常见做法有三类。

1. 注入式基准：在可控代码中人为植入已知缺陷。标签准确，但人工植入的缺陷与真实缺陷的分布存在差距。
2. 回溯式基准：选取历史上已修复的真实缺陷，回退到修复前的版本作为样本。贴近真实场景，但需要人工确认每条标签。
3. 私有样本：来自授权企业代码库的脱敏样本。最贴近业务，但不便公开复现，结论需要注明来源。

数据泄漏是需要警惕的问题。如果模型的训练数据中已包含某些公开漏洞的描述，它在这些样本上的表现会偏高。应对方法包括按时间切分样本、优先使用未公开的私有样本，以及在报告中说明样本的时间范围。

样本规模要覆盖多种编程语言、框架和缺陷类别。只使用一种语言或一类漏洞，结论无法外推到其他场景。

四、结果判定：真阳性、误报与重复

每条模型报告都要经过统一判定。一条报告要计为有效发现，至少满足三点：能定位到具体文件和位置；能说明触发条件或数据流走向；经人工复核确认存在风险。

去重是另一个容易被忽略的环节。同一个缺陷可能被以不同措辞描述多次，也可能在多次运行中反复出现。可以用一组稳定字段生成指纹，把重复项合并。

fingerprint = hash(
    normalize_path(finding.file),
    finding.enclosing_symbol,
    classify(finding.vuln_type),    # 映射到通用缺陷类别
    finding.sink_category
)

指纹字段应选择与表述无关、且在代码修改后保持稳定的内容。行号会随代码变动而改变，不适合放入指纹。函数名加缺陷类别与触发位置类型的组合，通常更可靠。

判定结果需要保留审计记录，包括复核人、判定依据和最终结论。这些记录是后续争议处理和版本对比的依据。

五、对照实验设计

比较两个版本的效果时，需要控制变量。输入样本、提示模板、上下文长度和时间预算都应相同。只要有一个条件不同，比较结果就不可信。

单次运行的结果带有随机性。应对同一输入多次运行，报告均值和波动范围。若两组结果的区间大幅重叠，差异就不具备统计意义。样本量较小时，这一点尤其重要。

版本迭代中还要检查回归。新版本可能在某类缺陷上有所提升，在另一类上却下降。按缺陷类别分组汇报，能暴露这类问题。只看总数，这类变化会被掩盖。

六、从发现到修复的闭环

审计的价值体现在修复上。一套完整的流程包括以下五个步骤。

1. 分级：依据影响范围和可利用条件确定严重等级。
2. 分派：明确责任人和修复时限。
3. 修复与验证：修复后补充回归测试，确认缺陷不再被触发。
4. 披露：对外部发现的问题，按负责任披露流程处理，并给予合理的修复窗口。
5. 归档：记录根因，用于改进编码规范和审计规则。

授权是前提。审计只应针对拥有或获得明确授权的代码库与系统开展。在未经许可的环境中运行扫描，即便技术上可行，也属于违规行为。

七、常见误区

• 把数量当能力。数字高不代表有效，需要结合精确率和严重性分布判断。
• 只看最好的一次结果。多次运行的均值更接近真实水平。
• 忽略复核成本。误报越多，人工处理负担越重，整体收益可能为负。
• 把模型输出直接当结论。尤其是高危结论，必须经过验证。
• 忽视基准过时。代码库持续演进，旧基准的代表性会下降，需要定期更新。

八、落地检查清单

• 明确评测目标：关注发现率、精确率，还是修复效率。
• 固定基准集与版本号，完整记录输入和输出。
• 每个版本至少运行若干次，报告分布而非单点数值。
• 设置去重规则和指纹字段，定期抽查是否存在误合并。
• 建立人工复核机制，抽样复核高置信度结果。
• 按缺陷类别、编程语言和严重等级分组汇报。
• 将发现接入修复与回归流程，跟踪关闭率。

审计结果的价值取决于评测方法是否严谨。把流程搭稳，任何模型或工具都能在同一标准下被客观比较。