Checkmarx 的新 SAST 引擎重点不在 LLM，而在后续处理

主流静态应用安全测试（SAST）供应商现在正在将大型语言模型（LLM）包裹在其传统扫描引擎周围，并将其称为下一代产品。但问题是，是否有任何一家真正有所不同，还是行业只是用 AI 标签重新包装了同样的噪音问题？

本周，Checkmarx 迈出了重要一步，推出了一款新的 SAST 引擎，该引擎结合了确定性规则扫描器、基于安全数据训练的 LLM，以及一个专门用于在结果到达开发团队之前将发现分类为真阳性或假阳性的引擎。公司声称其 F1 得分为 0.499，而类别平均水平为 0.20，并称在针对四个生产代码库的对比测试中，该引擎发现了领先前沿模型遗漏的 327 个真阳性——尽管它拒绝透露测试的是哪个前沿模型。F1 得分是用于评估自动检测模型性能的指标。

“三个引擎协同运行，提供统一保护：企业依赖了二十年的确定性规则基础、支持开发者和 AI 编码助手当前使用的每种语言的 AI 覆盖，以及在单个结果到达你的团队之前对真/假阳性进行分类的发现分析引擎（FAE），”Checkmarx 首席产品官 Jonathan Rende 在一份声明中表示。

编排作为实际产品

该架构似乎没有公司所说的那么新颖。Checkmarx 的 LLM 并非专为安全构建；它从使用专有安全数据进行微调的基础模型开始。Checkmarx 所推动的是编排层。也就是说，三个引擎自动协同运行，无需客户自行组装多引擎工作流。

“这两种解决方案本身都不够好，”Checkmarx 产品管理总监 Frank Emery 告诉 The New Stack，他指的是传统基于查询的扫描器和纯 LLM 工具之间的分歧。“我们的方法利用了确定性和非确定性 LLM 引擎，因此最终用户具有高度的可配置性和确定性，但他们也能快速支持新语言并覆盖更多代码库。”

一个趋于相同答案的类别

传统基于查询的工具是确定性和可审计的，但支持新语言速度慢，并且容易产生将工程师从生产性工作中拉开的假阳性。纯 LLM 扫描器可以立即处理任何语言，但产生非确定性结果，使得合规和治理困难。似乎每个现有供应商现在都在推出某种版本的两种方法。

区别在于集成发生的位置以及谁来进行管理。Checkmarx 的论点是，将复杂性隐藏在单个扫描触发背后才是实际的产品。用户在他们需要的地方获得确定性，在传统工具不足的地方获得语言覆盖，以及一个噪音过滤器——即他们的 FAE——它在假阳性出现之前就将其抑制，Emery 指出。

噪音问题变得更糟

噪音论点是最有力的。AI 编码工具显著推高了代码量，Emery 估计客户的提交量是几年前的一倍到一倍半。假阳性分类已经是应用安全团队的负担，在这种规模下表现不佳。

“如果你运行一次扫描得到 10 个发现，其中可能有几个是假阳性，但要找出这一点，你必须手动评估每一个，这会将开发人员或安全专业人员拉出他们的工作流程，”Emery 说。“随着开发速度加快和积压任务增长，这种噪音对团队来说变得越来越难以处理。”

在一份声明中，Checkmarx 首席执行官 Sandeep Johri 更直接地表达了这一观点：“我们的研究发现，今天交付的代码中有 75% 存在漏洞，因为 AI 创建代码的速度远远超过了保护其安全所需的速度。”

可攻击性作为新的优先级指标

在新引擎背后，Checkmarx 提出了一个称为“可攻击性”的优先级概念，这是一个可利用性得分，它追踪从源头开始的攻击路径，评估消毒剂、向量可访问性和业务相关性。其理念是将应用安全报告从原始漏洞计数转向真正需要修复的内容，为安全团队提供可用于董事会层面讨论的可辩护指标，Emery 说。

Checkmarx 的编排优先论点是否能在面对竞争对手的类似主张时站住脚，将取决于企业买家在自己的代码库上运行时的发现。

Checkmarx SAST 和发现分析引擎现在可在 Checkmarx One 平台上使用。现有订阅者将自动升级。