SASTとLLMセキュリティスキャナーはどう使い分けるか

すでに、似たような実験を試している方も多いのではないでしょうか。最先端のモデルにマージリクエストを読ませ、脆弱性スキャナーの役割を兼ねさせてみる。1件のマージリクエストであれば、これはかなりうまく機能します。モデルはコードを読み、そのコードが何を意図しているかを推論し、実在する問題を検出する。パターンベースのスキャナーが完全に見逃す問題を見つけることさえあります。

ここで次のように考えるのは、自然な流れです。1件のマージリクエストをこれだけ的確にレビューできるのなら、パイプライン全体でスキャナーを置き換えてもよいのではないか。しかし、そこで話が崩れます。エンタープライズ規模のコードベースで、すべてのコミットに対して最先端のモデルを主要なスキャナーとして動かす。この使い方は、1件のマージリクエストをレビューさせる場合と比べてコストが高く、挙動も予測しにくくなります。

プラットフォームチームやプロダクトチームでアプリケーションセキュリティを担当しているなら、そもそもこれは二者択一の問題ではありません。静的アプリケーションセキュリティテスト（SAST）かLLMスキャナーか、ではなく、どちらをどこで動かすか。この切り分けさえ正しく設計できれば、すべてのコミットで決定的なカバレッジを維持したまま、推論が本当に価値を発揮する場所にだけAIを追加できます。予測できない推論コストも、監査証跡の欠落も避けられる。両者を比較すると、次のようになります。

すべてのコミットをスキャンするコスト

優位：SAST

LLMに1件のマージリクエストをレビューさせるコストは、ごくわずかに見えるかもしれません。しかし同じモデルを、エンタープライズ規模のコードベースのすべてのコミットに向けた瞬間、計算が合わなくなります。スキャンのたびに、予測できない有料の推論呼び出しが発生する。そのコストは、コミットごと、1日ごとに積み上がっていきます。

一方SASTは、同じ量のコードを1回あたり1セント未満で、毎回同じように、予測可能な形で処理します。コミットごとのスキャンを安価かつ予測可能に保てるため、セキュリティのカバレッジが予算と競合しません。この役割をLLMに担わせると、コストは使用量に応じて膨らみ、見積もりも難しくなります。

一貫性と監査証跡の作成

優位：SAST

同じコードをLLMに2回通すと、検出される脆弱性が異なる場合があります。これはモデルが間違えたからではなく、サンプリングに基づく推論の仕組みそのものによるもの。この不安定さは、スキャンが実施された事実を証明し、監査に耐える信頼性を示す必要がある場面で課題になります。

監査担当者は、スキャナーを再実行して結果が一致することを確認し、その網羅性と正確性を独立して検証します。決定的なスキャナーはルールベースであるため、一貫性が設計に組み込まれている。再実行すれば、常に同じ結果が得られます。

脆弱性の種類

優位：両方

静的スキャナーとLLMスキャナーでは、得意とする脆弱性のクラスが異なります。決定的なスキャナーが想定しているのは、インジェクションの脆弱性、ハードコードされたシークレット、安全でない暗号処理の呼び出しといった、パターンベースの脆弱性。固定されたルールに従うため、実行するたびに同じ問題を検出します。

LLMによるスキャンは、仕組みが異なります。読み取れるのは、コードの周辺にある文脈、つまりシステムが何をすべきかを説明したエピックやイシュー、ドキュメント。スキャナー側には、これを処理する手段がありません。この文脈があるからこそ、認可チェックの欠落や所有権の前提の破綻といった、ビジネスロジックの問題を検出できます。文脈が利用できる状況であれば、LLMは、パターンベースのスキャナーが構造上どうしても捉えられない問題まで拾い上げられます。

検出結果の検証

優位：LLMスキャナー

決定的なスキャナーは候補を検出しますが、その検出結果が実際に悪用可能かどうかまでは判断できません。LLMは、もう一歩踏み込めます。欠陥を実際に誘発できるかどうかを試す簡易なテストを書くため、検出結果が本物かどうかが、キューに届く前に分かる。チームが誤検出の調査に時間を費やさずに済み、検出結果の品質に対するデベロッパーの信頼も高まります。

セキュリティプログラムは両方の併用へ向かう

セキュリティチームは、スキャナーの種類を一つに絞るのではなく、両方を動かすプログラムの構築へと向かっています。決定的なスキャンは、どんな場合でもすべてのコミットで実行されるベースライン。プログラムとして妥協できないカバレッジだからです。

その上に重ねる形で、LLMスキャナーが推論を要するチェックを担います。適用箇所は通常、すべてのコミットではなくマージリクエストの単位。決定的なスキャナーが構造上検出できない脆弱性を捉えられるのは、まさにこの領域です。両者を組み合わせれば、予測可能なコストでパターンを検出する決定的なスキャンと、ロジックの欠陥を推論で見つけ出すLLMスキャナーがそろい、網羅的なカバレッジが実現します。

GitLabをまだお使いでない方へ

高度なSASTがすべてのコミットをスキャンし、GitLabのセキュリティ向けLLMスキャナーであるセキュリティレビューフローが、推論に基づくレビューを追加します。いずれも同じパイプラインの中で完結します。GitLab Ultimateの無料トライアルを開始する

すでにGitLab Ultimateをご利用の方へ

すでに実行しているSASTスキャンと並行して動かすには、セキュリティレビューフローを有効化してください。

よくある質問

AIはSASTを置き換えられるのか

唯一のスキャナーとしては、置き換えられません。AIによるレビューは実在する問題を検出できますが、同じコードでも実行ごとに検出する脆弱性が変わったり、見逃したりします。また、エンタープライズ規模ですべてのコミットにLLMを走らせると、継続的かつ決定的に動作するよう作られたスキャナーよりもコストが高く、見積もりも難しくなります。

再現可能な監査証跡が、なぜコンプライアンスで重要なのか

SOC 2、PCI DSS、欧州連合のサイバーレジリエンス法といったセキュアコーディングのフレームワークは、再現可能で監査可能な証跡を求めています。スキャナーの結果とは、監査担当者が再実行して内容の一致を確認することで、独立して検証される情報。決定的なスキャナーは、この独立した確認を設計上サポートします。一方、確率的なモデルには、スキャンのたびに同じ結果になる保証がありません。

AIによるレビューはSASTに検出できない何を見つけられるのか

AIによるレビューが捉えられるのは、ビジネスロジックの欠陥です。認可チェックの欠落、所有権の検証の破綻、そしてコードがどう書かれているかではなく、何をすべきかを理解していなければ分からないバグ。AIによるレビューは意図についての推論を可能にしますが、これはパターンベースのスキャンが想定していない領域です。

セキュリティチームは両方を使うべきか

使うべきです。SASTとAIによるレビューは、検出を得意とする脆弱性の種類が異なります。SASTはすべてのコミットで継続的に実行し、AIによるレビューは、スキャナーが構造上検出できないビジネスロジックの脆弱性など、推論を要するチェックに充てるとよいでしょう。

関連リソース

• 高度なSASTでより高速かつスマートなスキャンを実現
• GitLab高度なSASTのドキュメント
• GitLab Duoセキュリティレビューフローのドキュメント
• GitLab Duoセキュリティレビューでスキャナーが見逃すロジックの欠陥を検出