Checkmarxの新しいSASTエンジンはLLMが重要ではない。その後の処理が重要だ。
Checkmarxは、決定論的ルールベースのスキャナー、セキュリティデータで訓練されたLLM、そして結果が開発チームに届く前に真陽性か偽陽性かを分類する第3のエンジンを組み合わせた新しいSASTエンジンを発表した。同社はF1スコアが0.499で、業界平均の0.20を大きく上回り、テストでは最先端モデルが見逃した327件の真陽性を発見したと主張している。アーキテクチャの中核はオーケストレーション層であり、3つのエンジンを自動的に統合し、顧客が独自にマルチエンジンワークフローを構築する必要をなくす。
主要な静的アプリケーションセキュリティテスト（SAST）ベンダーは現在、従来のスキャンエンジンに大規模言語モデル（LLM）をラップして、次世代製品と呼んでいる。問題は、それらのどれかが実際に異なるのか、それとも業界が単に同じノイズ問題をAIラベルでリブランドしただけなのかということである。
今週、Checkmarxは重要な一手を打ち、決定論的ルールベースのスキャナー、セキュリティデータで訓練されたLLM、そして結果が開発チームに届く前に発見を真陽性か偽陽性かに分類する専用の第3のエンジンを組み合わせた新しいSASTエンジンを発表した。同社はF1スコアが0.499であり、カテゴリ平均の0.20を大幅に上回り、また、4つの本番コードベースを用いた直接比較テストにおいて、主要な最先端モデルが見逃した327件の真陽性を発見したと主張している——ただし、どの最先端モデルとテストしたかは明らかにしなかった。F1スコアは自動検出モデルの性能を評価する指標である。
「3つのエンジンが連携して統一された保護を提供します。企業が20年間依存してきた決定論的ルール基盤、開発者やAIコーディングアシスタントが今日使用するすべての言語をカバーするAIベースのカバレッジ、そして1つの結果がチームに届く前に真陽性と偽陽性を分類する発見分析エンジン（FAE）です」とCheckmarxの最高製品責任者Jonathan Rendeは声明で述べている。
オーケストレーションが実際の製品
このアーキテクチャは、同社が示唆するほど斬新ではない。CheckmarxのLLMは専用に構築されたものではなく、独自のセキュリティデータで微調整された基盤モデルから始まっている。Checkmarxが推進しているのはオーケストレーション層である。つまり、3つのエンジンが自動的に連携して動作し、顧客が独自のマルチエンジンワークフローを構築する必要がないという考え方である。
「これらのソリューションのどちらも単独では十分ではありません」とCheckmarxの製品管理ディレクターFrank EmeryはThe New Stackに語り、従来のクエリベースのスキャナーと純粋なLLMベースのツールの違いについて言及した。「当社のアプローチは、決定論的エンジンと非決定論的LLMベースのエンジンの両方を活用するため、エンドユーザーは高度な構成可能性と決定性を備えつつ、言語を迅速にサポートし、より多くのコードベースをカバーできます。」
同じ答えに収束するカテゴリ
従来のクエリベースのツールは決定論的で監査可能ですが、新しい言語のサポートが遅く、エンジニアを生産的な作業から遠ざける偽陽性を生成する傾向があります。純粋なLLMベースのスキャナーは任意の言語を即座に処理できますが、非決定論的な結果を生成するため、コンプライアンスとガバナンスが困難になります。現在、すべての既存ベンダーが何らかの形で両方のバージョンを推進しているように見えます。
アプローチの違いは、統合がどこで行われ、誰が管理するかにある。Checkmarxの主張は、単一のスキャントリガーの背後に複雑さを隠すことが実際の製品であるということです。ユーザーは必要な場所で決定性を、従来のツールが不足する場所で言語カバレッジを、そしてノイズフィルター（FAE）を入手し、偽陽性が表面化する前に抑制する、とEmeryは述べている。
ノイズ問題は悪化する
ノイズに関する議論は最も有力である。AIコーディングツールはコード量を急激に増加させ、Emeryの推定では、顧客は数年前に比べて1倍から1.5倍のコードをコミットしている。偽陽性のトリアージはすでにAppSecチームにとって負担であり、そのような量ではうまくスケールしない。
「スキャンを実行して10件の結果が出た場合、そのうちの数件は偽陽性かもしれませんが、それを確認するには手動でそれぞれを評価する必要があり、その結果、開発者やセキュリティ専門家はワークフローから外れてしまいます」とEmeryは言う。「開発ペースが加速し、バックログが増大するにつれて、そのようなノイズはチームにとってますます扱いにくくなっています。」
声明の中で、CheckmarxのCEO Sandeep Johriはこの感情をより率直に述べている：「当社の調査によると、今日出荷されるコードの75％に脆弱性が存在します。なぜなら、AIがコードを作成する速度が、それを安全に保つために必要な速度をはるかに上回っているからです。」
攻撃可能性が新しい優先順位付け指標
新しいエンジンの背後には、Checkmarxが「攻撃可能性」と呼ぶ優先順位付けの概念があります。これは、ソースから攻撃経路を追跡し、サニタイザー、ベクターのアクセス可能性、ビジネス上の関連性を評価する悪用可能性スコアです。アイデアは、AppSecレポートを生の脆弱性数から実際に修正が必要なものへとシフトさせ、セキュリティチームに取締役会レベルの議論のための防御可能な指標を提供することです、とEmeryは述べている。
Checkmarxのオーケストレーション優先の主張が、同様の主張を行う競合他社に対して通用するかどうかは、エンタープライズバイヤーが自社のコードベースで実行した結果に依存するでしょう。
Checkmarx SASTと発見分析エンジンは、Checkmarx Oneプラットフォームで今すぐ利用可能です。既存のサブスクライバーは自動的にアップグレードされます。