Gemini 3.5 Flash Cyber:漏洞发现的增益来自专用模型,也来自调用预算

Gemini 3.5 Flash Cyber:漏洞发现的增益来自专用模型,也来自调用预算

Google DeepMind 的 Cyber 评测显示专用模型在固定调用预算下能发现更多已确认漏洞,但 Big Sleep、Chrome 扫描和内部案例都有明确实验边界,当前仍是受限试点。

先给判断:它展示的是受控漏洞发现能力,不是公开的自动修复 API

Google DeepMind 将 Gemini 3.5 Flash Cyber 定位为一个专门寻找、验证和修补软件漏洞的网络安全模型。独立评测页给出的结果很强:在固定调用次数下,它在 V8 上找到 55 个 unique confirmed issues,超过 mainline 3.5 Flash 的 47 个和 Claude Opus 4.6 的 36 个;Google Cloud 团队还报告过 2 小时内发现 RCE 与 memory-corruption 漏洞的内部案例。1
但这些结果有明确条件:CyberGym 的单份最终报告最多调用 5 次模型,Big Sleep 的评估关闭了安全护栏,Chrome 生产扫描使用未公开漏洞来防止 benchmark contamination,竞品分数还有 provider self-reported 的口径。模型目前也只通过 CodeMender 向政府和可信合作伙伴开展 limited-access pilot。它值得安全工程团队继续跟进,却不能按普通 Gemini API 的公开模型来理解。1 2

CyberGym:一次报告允许最多五次调用

CyberGym 用数百个真实世界的软件漏洞评估 AI agent。CodeMender 的配置不是让模型只回答一次,而是在生成一份最终报告前最多调用 5 次 Gemini 3.5 Flash Cyber,再将多个 agent 的结果合并。官方称,这种配置在 CyberGym 上取得了能与明显更大模型竞争的表现;同时注明对手结果来自各模型提供方自报分数。1
这里最重要的变量是调用预算。一次漏洞分析可以分成候选发现、复核、构造验证和报告整理,多次调用使模型有机会把前一轮的线索带入下一轮。因而 CyberGym 的结果更接近「专用模型加有限 agent 协作」的系统成绩,而不是单次 prompt 的裸模型成绩。原文没有给出每一步调用各自贡献多少,也没有把发现率、验证率和修补成功率拆开报告。

三个评测把同一能力放进不同环境

评测场景关键条件官方结果应如何解读
Big SleepGoogle 团队独立评估 Chrome、Safari 等复杂安全关键代码库;不启用安全护栏Flash Cyber 显著超过 mainline 3.5 Flash 和 3.6 Flash说明专用微调在高难代码库搜索中有增益,但关闭护栏会改变可比性 1
Chrome production commit scanning pipeline使用未公开漏洞,避免 Gemini 和竞品模型接触题目后污染基准相比 3.5 Flash 有显著提升更接近生产扫描流程,但未公开题目使外部复核受限 1
V8 JavaScript Engine固定调用次数,统计 unique confirmed issuesCyber 55,3.5 Flash 47,Claude Opus 4.6 36;有 10 个问题是另外两个模型都没有捕捉到的这是特定预算和代码库下的确认问题数,不是总体漏洞发现率 1
三组结果的递进关系是从公开漏洞集合,走到复杂代码库,再走到生产提交扫描和固定预算的引擎测试。它们共同支持「模型能在代码安全流程中找到更多候选问题」这一较窄的判断;它们不支持「模型已经能稳定修复所有漏洞」或「模型在所有代码库都优于通用模型」这类更宽的结论。

V8 的 55 对 47 对 36,说明了什么

V8 测试是页面中最容易被误读的一组数字。这里统计的是固定调用次数下、经过确认并去重的问题数,不是测试集上的 accuracy,也没有报告漏报率。Cyber Flash 找到 55 个,mainline 3.5 Flash 找到 47 个,Claude Opus 4.6 找到 36 个;其中 10 个问题没有被另外两个模型捕捉到。1
这个口径可以支持一个具体工程判断:在同一代码库和调用预算下,继续增加探索路径可能比单纯更换一个通用大模型更有价值。它不能告诉我们每个问题的严重性分布,也不能告诉我们修补是否成功。页面只说随着调用次数增加,Cyber Flash 还会持续发现新的代码路径和漏洞,至于增加多少次调用后收益递减,原文没有给出曲线。

生产案例的价值和边界

Google Cloud Vulnerability Research 团队报告称,使用该系统后,他们在 2 小时内发现了 public APIs 中的 remote code execution 漏洞,以及一个敏感生产服务中的 memory-corruption 漏洞;随后生成了一个被描述为 100% reliable 的 RCE exploit,并绕过 ASLR 和 W^X。1
这是一条实战信号,但不是一项普遍成功率。案例没有公开代码库规模、调用轨迹、人工参与程度、漏洞修复结果,也没有说明「100% reliable」对应多少次验证。因此更稳妥的解读是:模型已经能把漏洞线索推进到可验证 exploit 的阶段,安全团队可以用它缩短研究闭环;不能据此推断它会在无人监督下稳定攻击或自动修复生产系统。

安全护栏改变了比较条件

Big Sleep 的评测明确写出 without safety guardrails。Chrome 生产扫描的说明还提到,Opus 4.6 之后的部分竞品由于内置安全护栏会拒绝执行任务,因此没有展示这些结果。1
这带来一个不能绕开的比较问题:安全模型的分数既反映漏洞搜索能力,也反映模型是否被允许完成高风险步骤。若把拒答当成单纯的能力失败,会高估 Cyber 的相对优势;若把所有能执行 exploit 的模型都视为可上线,又会忽略安全控制本身的必要性。公开页面没有给出一套同时衡量发现能力、误报、拒答和修复质量的统一协议。

当前可用性:先看流程接入,不是看单价

Cyber Flash 的官方模型页把它概括为「快速、高效地发现并修复漏洞」,并列出 CyberGym、Big Sleep 和 Chrome 生产提交扫描三个方向,但没有给出一个面向公众的模型 ID、API 价格或开放注册入口。2
Google 的 Gemini API 定价页列出了 gemini-3.6-flashgemini-3.5-flash-lite 的公开价格,却没有列出 gemini-3.5-flash-cyber。结合官方博客所说的政府和可信合作伙伴 limited-access pilot,当前最合理的产品判断是:Cyber 是受控的代码安全系统组件,而不是可以按普通 token 单价采购的通用模型。3
对安全团队而言,值得继续验证的不是一张更高的排行榜,而是四个工程问题:多次调用的边际收益、漏洞确认与修补的分离指标、人工复核点,以及安全护栏如何与高风险研究流程共存。官方页面已经证明了第一步的可行性,也把后三个问题留在了公开数据之外。

Contenido relacionado

  • Inicia sesión para comentar.
More from this channel