SAST（Static Application Security Testing）は、ソースコードを解析し、SQLインジェクションやクロスサイトスクリプティング、不適切なデータフローなどを開発段階で発見する重要な技術です。

従来のSASTは、単なる文字列検索ではなく、AST（抽象構文木）による構文解析や、入力値が危険な処理へ到達する経路を追うテイント解析など、高度な静的解析技術を利用しています。

一方で、こうした解析だけでは判断が難しい領域があります。その代表例が、業務ロジックや認証・認可に関係する脆弱性です。

コードとしては正しいが、アプリケーションとしては危険

例えば、オンラインショップで注文情報を取得する処理を考えます。

本来であれば、

• 誰がログインしているか
• その注文は誰のものか
• 閲覧権限があるか

を確認する必要があります。

しかし、ある変更によって「注文者本人かの確認」だけが削除された場合、コード自体にはSQLインジェクションのような明確な危険処理が存在しないことがあります。

それでも結果として、他人の注文情報を閲覧できるようになるかもしれません。

問題は、危険な処理が追加されたことではなく、本来必要だった確認がなくなったことです。

「存在する危険」と「欠けている確認」は違う

従来のSASTは、「外部入力が危険な処理へ到達している」といった問題の検出を得意とします。

一方、業務ロジックの問題では、「この処理の前には、本来ユーザーの権限を確認する必要がある」というアプリケーション固有の意味を理解する必要があります。

さらに実際の開発では、Pull Requestによる変更によってリスクが生まれることもあります。

例えば、

という変更です。

追加された危険なコードはありません。

しかし、数行の削除によって、「他人の注文情報を取得できる」状態が生まれた可能性があります。

リポジトリ全体の文脈と変更内容を見る

こうした問題を評価するには、変更されたコードだけではなく、

• 関連するAPI
• 認証・認可処理
• データモデル
• データフロー
• 周辺コード
• Pull Requestの変更内容

などを組み合わせて理解する必要があります。

そこで注目されているのが、AIを利用してコードベースの文脈を理解するアプローチです。

本稿では、こうした考え方を便宜上、「AI推論型AppSec（アプリケーションセキュリティ）」と呼びます。

AI推論型AppSecでは、単に、「危険な処理が書かれているか」を見るだけではなく、「このコードベースの中で、この変更によって何が許されるようになったのか」という観点まで評価対象を広げます。

例えば、

• 認証・認可チェックの欠落
• IDOR / BOLA（オブジェクト単位の認可不備）
• 権限境界の取り違え
• 二重返金
• 利用回数制限の削除
• 状態遷移の不整合

などは、アプリケーション全体の文脈を理解することで見えてくる可能性があります。

従来SASTの強みを、AIによる文脈理解で補完する

もちろん、AIを使えばすべての脆弱性を検出できるわけではありません。

AI推論型AppSecは、従来のSAST、DAST、SCA、ペネトレーションテストなどを置き換える万能技術ではなく、従来の解析では評価が難しかった領域を補完するアプローチと考えるのが適切です。

従来のSASTは、既知の脆弱性パターンやセキュアコーディング規約への違反を統一されたルールで、網羅的かつ継続的に検出することに強みがあります。そのため、組織的なセキュリティ基準の運用や、コンプライアンス要件への対応、監査のための証跡作りを支援します。

従来のSASTが、「危険な処理が書かれている」ことを見つけ、そこにAIによる文脈理解を組み合わせることで、「変更によって何が許されるようになったか」まで評価対象を広げます。

コード生成AIの普及によって変更量が増えていく中、この「変更の意味を見る」という視点は、今後のAppSecでさらに重要になっていくでしょう。