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 平臺上使用。現有訂閱者將自動升級。