关注 霍格沃兹软件测试开发 公众号回复「资料」, 领取人工智能测试开发技术合集摘要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.0CI/CD里保留三份证据第一份是触发证据扫描策略、仓库配置、运行时间和工具版本。第二份是发现证据代码位置、攻击路径、严重性与建议。第三份是处置证据确认漏洞、误报、接受风险或修复并关联对应PR。每次平台能力或配置变化后用固定数据集回放。新增命中不一定都是提升可能是误报告警减少也不一定是优化可能是触发条件失效。只有和真值集对比才能解释变化。测试工程师下一步能做什么从10个历史安全缺陷开始补5个安全反例分别在四种配置仓库中跑一遍。把触发状态、召回、误报、稳定性和处理时间做成一页报告。这套方法不局限于GitHub。任何AI安全扫描、AI代码评审或Agent检查都适用先明确它有没有运行再判断发现是否正确最后衡量它给团队增加了多少处理成本。覆盖范围扩大只代表更多代码被看见。能不能稳定发现真正风险、能不能说明为什么没发现才决定这项能力是否值得进入发布门禁。 GitHub AI Scan不再依赖CodeQL默认配置：覆盖扩大后，怎么证明漏洞没漏？
关注 霍格沃兹软件测试开发 公众号回复「资料」, 领取人工智能测试开发技术合集摘要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.0CI/CD里保留三份证据第一份是触发证据扫描策略、仓库配置、运行时间和工具版本。第二份是发现证据代码位置、攻击路径、严重性与建议。第三份是处置证据确认漏洞、误报、接受风险或修复并关联对应PR。每次平台能力或配置变化后用固定数据集回放。新增命中不一定都是提升可能是误报告警减少也不一定是优化可能是触发条件失效。只有和真值集对比才能解释变化。测试工程师下一步能做什么从10个历史安全缺陷开始补5个安全反例分别在四种配置仓库中跑一遍。把触发状态、召回、误报、稳定性和处理时间做成一页报告。这套方法不局限于GitHub。任何AI安全扫描、AI代码评审或Agent检查都适用先明确它有没有运行再判断发现是否正确最后衡量它给团队增加了多少处理成本。覆盖范围扩大只代表更多代码被看见。能不能稳定发现真正风险、能不能说明为什么没发现才决定这项能力是否值得进入发布门禁。