AI每次提交都查漏洞，真正的升级是把证明链放进评审
内容提要
Google 对每次代码提交进行 AI 安全扫描，用程序分析验证漏洞路径，夜间复查跨提交问题，修复补丁交人工评审。核心是“发现、证明、复核、修复”证据链，由模型提出假设、分析验证真伪，避免仅依赖模型自信。团队可先选高风险目录试点，记录误报与评审耗时，再决定是否阻断合并。
延伸解读
证据链比全自动更值得借鉴
文章强调Google方案的核心不是“全自动”，而是“发现、证明、复核、修复”的证据链。模型负责提出漏洞假设，程序分析验证路径是否真实可达，夜间扫描补查跨提交问题，修复补丁再交人工评审。对团队而言，直接照搬全自动流程风险高，更稳妥的是先建立可审查的证据链，让每一步都有明确输出和责任人，避免仅凭模型自信就阻断合并。
精度数字不能单独衡量系统好坏
Google披露局部威胁模型误报率可降至3%，分诊Agent精度超92%，但这些来自内部系统，适用代码类型、召回率和样本量未公开。文章提醒，安全扫描还需看召回率、严重漏洞分层、平均处理时间、被开发者推翻的原因以及漏报如何被后续层捕获。只报三条且全对的系统，仍可能漏掉最危险的第四条，因此不能仅凭精度判断是否可用。
增量扫描有明确适用边界
增量扫描适合反馈要快、变更可定位的代码库，但配置漂移、运行时权限、供应链依赖以及多个提交共同形成的漏洞，必须靠夜间或周期性全局扫描补位。自动修复也可能改变行为或只堵住表面路径，补丁需要单元测试、攻击回归测试和所有者审批。团队还需防范源码发送范围、模型日志留存、第三方依赖许可及提示注入等风险。
试点评估应关注证据链指标
文章建议先选一个高风险仓库，定义三类漏洞与阻断阈值，只给Agent只读权限，要求每条告警附文件位置、入口、危险点和可达路径，并用现有测试验证补丁。评估时别只统计告警数量，至少记录高危问题召回线索、每百次提交的误报、开发者确认一条告警所需时间、补丁一次通过率及同类漏洞是否再现。若误报下降但人工核验时间上升，系统仍可能拖慢交付。
Q&A
Google 的 AI 安全扫描具体是怎么运作的？
Google 对每次代码提交运行 Agent 扫描，用程序分析验证漏洞路径，夜间复查跨提交问题，修复补丁交回人工评审。核心是“发现、证明、复核、修复”证据链，模型提出假设，程序分析验证真伪。
为什么说 AI 安全扫描不能只靠模型自信？
模型能快速拓展假设空间，但不擅长独自给出确定性结论。Google 方案让生成式 Agent 和确定性程序分析互相约束，把最后责任留在人类评审，避免仅依赖模型自信。
普通团队如何低成本试点 AI 安全扫描？
先选一个高风险目录（如鉴权、中间件、支付或基础设施脚本），只扫描变更差异及其一到两层依赖。把高置信发现变成必须处理的评审项，中低置信发现放进异步队列，记录开发者接受、驳回和原因，逐步校准规则。
增量扫描有哪些适用边界和风险？
增量扫描适合反馈要快、变更可定位的代码库；对配置漂移、运行时权限、供应链依赖和多个提交共同形成的漏洞，必须靠夜间或周期性全局扫描补位。自动修复可能改变行为或只堵住表面路径，补丁需要单元测试、攻击回归测试和所有者审批。
评估 AI 安全扫描试点时应该看哪些指标？
别只统计告警数量。至少同时记录高危问题召回线索、每百次提交的误报、开发者确认一条告警所需时间、补丁一次通过率，以及同类漏洞是否再次出现。若误报下降却人工核验时间上升，系统仍可能拖慢交付。
一周内可以执行的 AI 安全扫描试点步骤是什么？
选择一个高风险仓库；定义三类漏洞与阻断阈值；只给 Agent 只读权限；要求每条告警附文件位置、入口、危险点和可达路径；用现有测试验证补丁；最后统计误报、漏报线索和评审耗时。先证明证据链可靠，再讨论自动合并。
