AI News HubLIVE
站内改写4 分钟阅读

超越Fable:本地LLM能否取代云端AI进行安全代码审查?

研究表明,在正确框架下,本地LLM(如Qwen3.6-35B-A3B)在安全代码审查中可以产生与云端前沿模型相当的结果,但需要结合云端模型进行编排和报告整合,且源代码永远不离开本地机器。

来源Hacker News AI作者: dubbel

在网络安全领域,安全代码审查是最有价值但也最劳动密集的服务之一。大型语言模型(LLM)已成为这一过程中的得力助手:它们能扫描数千行代码,交叉引用CWE数据库,并发现即使经验丰富的审查员也可能遗漏的模式。然而,有一个问题:许多渗透测试接受方不希望将自己的源代码分享给云端托管服务,尤其是在金融、政府及关键基础设施领域。将专有代码发送给第三方LLM会导致保密性和数据驻留风险,仅凭与LLM提供商签订的合同保障无法完全缓解。

由此产生的困境是:最好的LLM是云端托管的,而那些最需要安全审查的公司,往往因为顾虑而放弃使用这些领先能力。那么,云端托管模型的领先优势到底有多大?我们着手回答一个实际问题:本地托管的开放权重模型能否产生与前沿云端模型相当的安全发现?

我们的答案是:几乎可以——但需要正确的框架。我们进行了一系列实验,测试本地LLM的极限,发现它们与基于云端的模型协同工作效果最佳,同时无需向云端泄露源代码:

一个仅有约30亿活跃参数的Qwen3.6-35B-A3B模型,完全运行在Mac笔记本电脑上,源代码不离开机器,在金融科技应用和投票应用上产生的发现集大小与前沿云端模型(GLM-5、Claude Opus 4.6)相当,并且有一些自己独有的发现。它不需要任何人工提示,每次代码库审查完成时间不到90分钟。对于核心任务——阅读代码、发现漏洞、分类严重性、筛选CVE输出——本地模型现在已与前沿模型处于同一水平。

需要注意的是,发现数量持平并不等同于能力持平。我们的观点是,本地模型具有足够的竞争力,可以作为管道的一部分发挥作用,并且其发现被专家认为具有相同的影响力。本研究侧重于定量方面,但发现质量已通过渗透测试专家和开发团队的验证。

本地模型目前尚不擅长的是设计审查和整合结果。我们发现最有效的管道将这两项编排任务委托给云端前沿模型——但在两个阶段中,云端都不会看到源代码。我们称之为“Source-local”:专有源代码永远不会离开机器。元数据(文件树、模式、路由、依赖清单以及生成的步骤提示)会传递到云端,这可能包含内部名称、目录结构和架构。准确的承诺是“没有源代码离开机器”,而不是“什么都没有离开”。

使这一方法起作用的框架由三部分组成:

  1. 结构化分解和提示生成——云端模型将审查分解为聚焦的步骤,并仅从元数据(文件树、模式、路由——无源代码)生成步骤提示。
  2. 本地工具和LLM输出——提示在本地执行,运行标准安全工具(如bundler-audit、npm audit、Semgrep、Brakeman),并将其JSON输出提供给本地模型进行上下文筛选和额外漏洞搜寻。
  3. 报告整合——云端最终步骤将步骤级发现合并为可交付的报告。

第一部分和第三部分不需要向云端暴露源代码;第二部分完全在本地运行。由此产生的最佳实践是:云端用于提示工程,本地用于执行,云端用于整合。云端模型从不查看源代码——它设计审查;本地模型不需要广泛的架构推理——它执行针对打包文件的聚焦检查。

利用Fable 5:基于云端的编排层是模型无关的。第一和第三阶段的编排器不必是无限前沿模型;具有网络安全护栏的模型也能胜任。Claude Fable 5(2026年6月发布)带有精心设计的网络限制,它设计审查提示并整合发现,没有拒绝且质量不损失,完全匹配Claude Opus 4.8在这些角色中的表现。这并不令人惊讶:设计和整合防御性审查是知识和结构工作,而非利用,且编排器从不接触源代码。

关键要点:

  1. 没有单一模型能发现所有问题。所有模型发现的并集显著大于任何单个模型的输出:每个模型发现了不同类别的漏洞:Claude擅长架构推理,GLM-5擅长数据流追踪和工具集成,Gemma4擅长文件集内的行级代码模式匹配,Qwen3.6擅长广覆盖和激进的严重性校准。对从业者的启示:运行“第二意见”模型确实能扩大覆盖面,即使使用更小的模型也是如此。
  2. 提示工程比模型大小更重要。一个结构良好的流程使每个模型都变得更好。例如,Gemma4——在约38亿活跃参数预算下运行——发现了三个更大的前沿模型遗漏的真实发现。它运行成本低但能力具有竞争力,这里的差异不是原始能力而是提示设计。这需要准备:当跳过框架准备并给Gemma4一个单一提示时,它产生了不完整的结果并丢失了输出指令。当相同的范围被分解为六个聚焦的微任务,并附上明确的文件路径和grep命令时,Gemma产生了可操作的发现,包含具体的行号和代码证据。两种情况下都没有幻觉。这表明本地模型的质量上限比预期高——但达到它需要框架准备来引导搜索。我们发现这种准备工作本身可以自动化:Claude仅从文件树(无源代码)生成步骤提示,而Qwen执行这些自动生成的提示比任何云端模型的单个提示审查发现了更多问题。重要的一点是:当Claude为更小的模型准备提示时,那个更小的模型比Claude负责整个测试时的审查发现更多。
  3. 报告质量差异很大。较大和前沿模型的报告质量明显更好,这再次表明它们在“Source-local”审查中仍有位置,其中本地模型执行实际测试:Claude Opus的报告最即时可用,但需要最多的人工提示(约6次提醒);GLM-5产生了最全面的可交付成果集,但偶尔的幻觉输出引用损害了报告质量;Qwen产生了结构良好的逐步报告,具有正确的CWE映射和没有幻觉证据;Gemma4的输出需要最多的后处理。
  4. 审查编排器可以是任何有能力的模型——甚至受网络限制的Fable。受网络限制的前沿模型是一个称职的编排器:Fable 5产生了完整的提示包和严格的整合,没有拒绝,与Opus 4.8在这些角色中没有明显的质量差距。编排器的选择会改变发现的内容:Fable的针对性提示可靠地恢复了已知的“哨兵”漏洞,但产生了更紧凑的集合,而Opus的更广泛提示产生了更大且在某些方面更严重的集合——包括Fable分支从未提到的关键问题(负投票零成本投票、未经认证的选票塞入)——代价是错过了它未特别针对的哨兵。与执行器一样,并集优于任一编排器:Fable并不比Opus“更好”——它们最好并行运行。对从业者的启示:编排应被视为管道中很大程度上模型无关的部分:你可以使用任何你有访问权限的有能力云端模型(受限或非受限)。并且为本地模型运行两个提示设计会扩大覆盖面,就像使用第二个执行器一样。混合搭配以获得最佳结果。

实验设置:我们使用了两个生产代码库,具有不同的技术栈和威胁档案:Fintech Dashboard(Next.js / TypeScript / React)和一个投票应用。