昨天 Google Threat Intelligence Group 公开了一套内部使用了 10 个月的系统Agentic Vulnerability Discovery HarnessAVDH。公开数据很扎眼一次涉及被盗企业代码仓库的事件响应中 2 天发现 100 个真正的 Critical 漏洞过去 10 个月里这套 Harness 已经分析数千万行代码 执行数千条 Pipeline 产生数万条 Finding目前公开材料里提到相关工作已经推动了12 个 CVE的分配还有十多个问题处于披露流程中。这些数字足够做标题。但我看架构时最想抄的不是“多 Agent”而是另一件事他们没有让一个模型从头到尾相信自己而是专门设计了怀疑、验证和证据升级流程。这比“再加一个 Reviewer Agent”具体得多。传统 SAST 为什么和 LLM 审计不是同一种东西传统规则扫描很擅长危险函数 已知模式 不安全 API 依赖漏洞但代码漏洞经常需要理解这个入口普通用户能不能访问 这段代码实际上会不会被执行 这个参数经过哪些校验 管理员路径和普通路径是不是共享了状态Google 文章里就特别提到LLM 的优势之一是能区分普通用户可访问代码 管理员限制代码 根本不会执行的代码这属于语义和控制流理解。但“模型觉得这里有漏洞”远远不够如果一个 Agent 扫 1000 万行代码然后输出发现 80,000 个潜在漏洞安全团队基本没法用。真正重要的是True Positive Density也就是人真正值得看的发现比例AVDH 的设计重点之一就是把模型生成的候选发现继续送进结构化验证而不是把第一轮猜测直接变成工单。我会把代码安全 Agent 拆成五个角色Scout → Analyst → Skeptic → Validator → ReporterScout快速扫描潜在攻击面。目标高召回宁可多找一点。Analyst理解数据流权限调用关系用户可控输入敏感 Sink。Skeptic专门反驳“为什么这不是漏洞”找前置校验不可达路径管理员限制类型约束框架自动保护。Validator在受控环境里验证可复现性。Reporter只有证据达到阈值才进入人工队列。为什么 Skeptic Agent 很重要多数多 Agent Demo 的第二个 Agent 是Reviewer但 Reviewer 很容易只是换一种语言同意第一个模型。更有用的 Prompt 应该故意对抗你的任务不是证明漏洞存在。 你的任务是尽最大努力证明这个结论是误报。这会产生真正的Adversarial Review一个 Finding 不应该只有 description最少publicrecordVulnerabilityFinding(StringfindingId,Stringrepository,Stringcommit,Stringfile,intstartLine,intendLine,StringvulnerabilityClass,AttackPreconditionprecondition,ListCodeEvidenceevidence,ListCounterEvidencecounterEvidence,ValidationStatusvalidation,doubleconfidence){}其中最容易被漏掉的是CounterEvidence不是只记录“为什么像漏洞”还记录“有哪些证据说明它可能不是”。代码审计 Agent 最怕上下文切错例如sanitize()定义在另一个模块。如果 Agent 只看到当前函数它可能误报。所以 Repository Context Builder 很关键。我会按 Finding 动态装配当前函数 调用者 被调用函数 鉴权中间件 相关类型 配置 测试而不是简单把整个仓库塞进 1M Context。Call Graph 和 LLM 应该组合确定性工具先生成AST Call Graph Dependency Graph Taint CandidateLLM 再解释这条路径在业务上是否可利用这比纯 LLM 从几十万行源码里自由搜索稳定得多。一个最小 PipelineRepo Snapshot ↓ Static Extraction ↓ Candidate Entry Points ↓ Scout Agent ↓ Semantic Analysis ↓ Skeptic Review ↓ Sandbox Validation ↓ Human Security Review ↓ Disclosure / Fix注意顺序。不是LLM → CVE为什么要固定 Commit安全扫描结果必须绑定repository commit_sha否则今天发现foo.java:128明天代码一变证据就无法复现。所有 Finding 都应该基于不可变 Snapshot。真实代码仓库泄露以后时间就是关键变量Google 文章的背景非常现实攻击者拿到企业源码以后也可以用 AI 快速找漏洞。这时候防守方过去的流程人工分模块 →几周代码 Review →修复可能已经太慢。这就是为什么 AVDH 在事件响应里有意义谁先发现可利用路径 谁先修变成时间竞赛。但不要把安全 Agent 接到生产代码以后自动修至少第一阶段不要。原因误报可能改坏业务 漏洞修复可能破坏兼容 补丁可能只遮住表面 安全变化本身需要 Review更合理Agent 找 Agent 验 Agent 生成 Patch Candidate Human Review 测试 Canary漏洞验证环境必须隔离如果系统可以自动构造攻击输入验证 RCE、SQL Injection、SSRF 等风险绝对不能直接在生产网络测试。需要Sandbox No Production Credentials Restricted Network Synthetic Data Disposable Environment并给每类验证设策略。我会给验证 Tool 加 RiskpublicrecordSecurityTool(Stringname,SecurityActionTypetype,RiskLevelrisk,booleansandboxOnly,booleanhumanApprovalRequired){}例如AST parse LOW Local fuzz MEDIUM Exploit validation HIGH External target scan CRITICAL高风险动作必须被平台硬限制。“找到了 100 Critical”不是唯一指标如果评价安全 Agent我会看True Positive Rate Critical Recall False Positive / KLOC Human Review Minutes / Finding Time to Validated Finding Duplicate Finding Rate Patch Acceptance Rate以及最关键的Missed Critical一个公开 CVE 数量也不能直接等于模型能力12 个 CVE 是很强的现实证据但它仍然混合了模型HarnessMandiant 专家经验静态分析验证人工 Disclosure。所以我不太喜欢把这种案例写成Gemini 自动发现 12 个 CVE更准确的是专家设计的 Agentic Harness 让模型能力变成了可重复安全流程这才是能复制的部分。安全 Agent 的 Prompt 反而不应该太自由例如 Scout 输出必须遵循{entry_point:...,user_controlled_input:...,sensitive_sink:...,required_privilege:...,attack_path:[...],missing_evidence:[...]}不能只给“这里可能有一个严重漏洞。”结构化结果才方便后续 Skeptic 和 Validator 消费。证据必须能被人快速确认安全工程师最不想看到的是模型写 2000 字解释最想看到Source → Transformation → Sink → Missing Check → Reproduce例如POST /upload → filename → path.join(root, filename) → no canonicalization → filesystem write一分钟就能判断是否值得继续。我很认同 AVDH 背后的一个方向AI 不一定要替代最强的安全专家。更现实的价值是把专家从海量普通代码检查里解放出来专门处理复杂利用链 业务逻辑漏洞 架构级问题 真正高价值目标Google 文章最后也明确强调的是“human expertise multiplier”。这比“全自动黑客 Agent”更接近生产价值。如果企业今天开始做我会从哪里开始不要一开始扫全公司。先选一个 Web 服务 10—30 万行代码 有完整测试环境 有安全专家参与建立 50—100 个历史漏洞/已修复问题作为评测集。比较传统 SAST LLM 单 Agent 多 Agent Harness看Recall Precision Review Time Cost最后一个判断AVDH 最值得企业安全团队关注的不是“Agent 会不会自动找到零日”。更重要的是它展示了一种新的代码审计生产线。过去扫描器出结果 →人过滤海量告警现在可能变成静态工具提供候选 →Agent 理解上下文 →另一个 Agent 主动反驳 →Sandbox 验证 →人只看高价值证据这套流程真正把 AI 的语义能力放在了传统扫描器和人类专家中间。而不是让一个大模型坐在最上面宣布“这里有漏洞”。两天 100 Critical、12 个 CVE 的真正意义我觉得就在这里不是模型更会猜漏洞而是安全团队开始拥有一条可以规模化运行的 AI 审计流水线。Finding 也需要生命周期不是发现以后就“Open”我会设计publicenumFindingStatus{CANDIDATE,UNDER_SKEPTIC_REVIEW,NEEDS_CONTEXT,VALIDATION_QUEUED,VALIDATED,REJECTED_FALSE_POSITIVE,HUMAN_CONFIRMED,PATCH_PROPOSED,FIXED,DISCLOSED}这样安全团队能看到漏斗而不是一片红色告警。人工安全专家应该把时间花在哪里理想状态不是人完全退出而是把人放在高价值节点模型争议 高危验证 业务逻辑 Exploit Chain Patch Review Disclosure普通候选搜索、重复验证和证据整理尽量交给 Harness。这也是为什么“节省多少人工小时”不一定是唯一目标。安全团队更关心同样 10 个专家 能覆盖多少倍代码一个非常实际的误报复盘机制每个被人判为 False Positive 的 Finding不应该直接关闭。提取原因AUTH_GUARD_PRESENT UNREACHABLE_CODE SANITIZED_UPSTREAM TEST_ONLY_CODE FRAMEWORK_PROTECTED INVALID_DATAFLOW下一轮 Skeptic Agent 可以利用这些标签做专门训练和评测。一个月以后就能回答我们最大的误报来源是什么安全 Agent 的知识库和业务 RAG 不应该混用安全上下文通常包含Framework Security SemanticsCVEInternal Secure Coding RulesHistorical FindingsArchitectureThreat Model。这些数据权限往往更高。建议使用独立安全知识域甚至独立 Vector Store / Artifact Store避免普通 Agent 检索到漏洞细节、攻击路径和未披露问题。最后的发布门禁应该看“验证后的风险”不是 Candidate 数量一个 Agent 版本从10,000 Candidates变成30,000 Candidates不代表变强。如果 Human Confirmed 没增加Review 成本反而涨了。真正的优化目标更接近Validated Critical / GPU-hour Human-confirmed / Review-hour Critical Recall False Positive Rate这才符合安全团队的生产目标。