摘要：GitHub扩大AI Scan覆盖范围，不再要求仓库启用CodeQL默认配置。本文说明扫描覆盖变广后，如何建立可解释的漏洞样本、误报门禁和仓库级回归。 安全平台打开一个开关，原来没有CodeQL默认配置的仓库也开始收到AI漏洞告警。管理者看到的是“覆盖率上去了”，研发看到的可能是：同一段代码在不同仓库结论不同，旧漏洞没报，新PR却突然多了十几条建议。
GitHub 9月16日更新显示，PR中的AI Scan不再要求仓库启用CodeQL默认配置；只要相应的代码扫描与AI Scan在仓库、组织或企业层启用，符合条件的仓库就能获得更广覆盖。目前该变化处于公开预览范围。
覆盖扩大是好事，但它同时改变了测试问题：过去我们验收“扫描有没有开启”，现在必须验收“在不同配置背景下，扫描行为是否仍然可理解”。
先别把AI Scan当成CodeQL替代品
两者都能发现安全问题，不代表能力边界相同。确定性规则擅长稳定识别已建模的数据流和模式，AI扫描可能更善于理解局部上下文与新型代码写法，但输出也可能受上下文、模型或提示变化影响。
测试计划应该把它们看成两个信号源：CodeQL命中、AI Scan命中、二者都命中、二者都没命中。重点关注最后两类：只被一种发现的样本能揭示能力互补；都没发现但人工确认存在的漏洞必须进入回归集。
建立一套“有答案”的安全样本
不要拿生产仓库里所有历史告警直接算准确率，因为很多告警本身没有真值。先构建小规模、可解释的数据集，至少包括SQL注入、路径穿越、命令注入、弱鉴权、敏感信息泄露，以及看起来危险但经过安全编码的负样本。
CASES = [
{"id": "sql-01", "vulnerable": True, "severity": "high"},
{"id": "path-01", "vulnerable": True, "severity": "high"},
{"id": "safe-sql-01", "vulnerable": False, "severity": None},
]
def evaluate(findings):
by_id = {x["case_id"]: x for x in findings}
assert by_id["sql-01"]["detected"]
assert by_id["path-01"]["detected"]
assert not by_id["safe-sql-01"]["detected"]
代码不复杂，难的是样本设计。每个样本都要说明漏洞成立的前置条件、攻击路径、正确修复和容易误报的安全写法。没有这些，所谓Benchmark只是把工具输出再抄一遍。
覆盖扩大后，先测配置矩阵
至少准备四类仓库：启用CodeQL默认配置；使用高级配置；未启用CodeQL但启用AI Scan；组织策略已开启但仓库因权限或类型不符合条件。
同一个PR分别提交，记录是否触发、扫描耗时、命中项、严重级别和权限错误。若没有结果，要区分“扫描后无发现”和“根本没运行”。这两个状态在报表里绝不能都显示为0。
还要测试组织、企业和仓库三级策略覆盖。上级开启、下级关闭是否允许；仓库转移组织后是否继承新策略；Fork与外部PR是否执行；历史PR重开是否补跑。这些配置问题往往比模型本身更容易造成漏扫。
告警多了，误报成本会迅速放大
假设新覆盖100个仓库，每个PR只多一条误报，一天也可能产生数百次人工确认。测试指标不能只看召回率，还要看每百个PR误报数、开发者处理时间、重复告警率和被静默忽略的比例。
对误报做聚类：同一根因的50条告警不应被当成50种问题。建立抑制规则时则要验证范围，不能为了消掉一个误报，把真正漏洞一起屏蔽。
建议设置分层门禁：高置信度、高严重级别且有明确攻击路径的告警阻止合并；中等置信度进入人工复核；低置信度先做影子观察。预览功能尤其不适合第一天就全量阻断。
AI安全扫描也需要稳定性测试
同一PR连续运行三次，核心高危结论应相对稳定。若每次发现不同问题，要记录交集、并集和首次命中率；不能挑结果最多的一次当作能力证明。
代码做等价改写也很重要：变量改名、函数移动、增加无关日志后，漏洞本质没变，扫描结论不应突然消失。反过来，真正修复输入校验后，告警应该消失且不会换一个表述继续重复。
def stability(runs, critical_id):
hits = sum(critical_id in run for run in runs)
return hits / len(runs)
assert stability([{"sql-01"}, {"sql-01"}, {"sql-01"}], "sql-01") == 1.0
CI/CD里保留三份证据
第一份是触发证据：扫描策略、仓库配置、运行时间和工具版本。第二份是发现证据：代码位置、攻击路径、严重性与建议。第三份是处置证据：确认漏洞、误报、接受风险或修复，并关联对应PR。
每次平台能力或配置变化后，用固定数据集回放。新增命中不一定都是提升，可能是误报；告警减少也不一定是优化，可能是触发条件失效。只有和真值集对比，才能解释变化。
测试工程师下一步能做什么
从10个历史安全缺陷开始，补5个安全反例，分别在四种配置仓库中跑一遍。把触发状态、召回、误报、稳定性和处理时间做成一页报告。
这套方法不局限于GitHub。任何AI安全扫描、AI代码评审或Agent检查都适用：先明确它有没有运行，再判断发现是否正确，最后衡量它给团队增加了多少处理成本。
覆盖范围扩大，只代表更多代码被看见。能不能稳定发现真正风险、能不能说明为什么没发现，才决定这项能力是否值得进入发布门禁。
