SASTスキャナーが見逃すビジネスロジックの脆弱性を検出する

オブジェクトレベル認可の不備は、OWASP API Security Top 10の第1位に位置づけられています。またOWASPも指摘しているとおり、従来の静的アプリケーションセキュリティテスト（SAST）ツールは、アクセス制御の欠陥の検出を苦手としてきました。認可チェックの欠落とは、本来あるべきコードが存在しないという状態です。パターンを照合するスキャナーには、照合すべき対象そのものがありません。このギャップを見つけられるのは、そのエンドポイントが本来何を適用すべきかをあらかじめ把握している場合だけです。

GitLabは、パターンベースのスキャナーが見逃すビジネスロジックの脆弱性を捉えるために、GitLab Duo Agent Platform上でBusiness Logic Security Analyzerを開発しています。現在、GitLab.comをご利用のGitLab Ultimateのお客様を対象に、早期アクセスとして提供しています。

正しいコード、誤った意図

アプリケーションセキュリティチームであれば、次の3つはいずれも見覚えのあるものでしょう。

1. リクエストから注文IDを受け取り、その注文を誰が所有しているかを確認しないまま注文内容を返すエンドポイント。
2. ユーザープロファイルのroleフィールドが、クライアントから送られてきたJSONをそのまま受け入れてしまう。
3. ユーザーIDが連番の整数になっている。

いずれもコードとしては正しく動作し、危険なシンクに信頼できないデータが到達するわけでもなく、既知の不正なシグネチャが現れるわけでもありません。そのため、従来のSASTエンジンが備えるテイント解析やパターンルールの大半をすり抜けます。ところが、これらが連鎖すると、攻撃者は全顧客の注文情報と管理者ロールを手にできてしまいます。

リポジトリ全体をスキャンする理由

エージェントがコードを書くようになり、GitLabのお客様全体でコードベースの規模は最大500%まで拡大しました。4月までに公開されたCVEは、Forum of Incident Response and Security Teamsが2月に示した予測を46%上回るペースで増えています。コードを生成するAIモデルは、既存の弱点を発見し、つなぎ合わせるコストも同時に引き下げました。そのしわ寄せが集中するのが認可のロジックです。デベロッパーもエージェントも、チェック自体は1〜2行で書きます。しかし、その1〜2行が抜け落ちたとき、欠落に気づかれないまま残ってしまうケースが少なくありません。GitLabでプロダクトマネジメント担当バイスプレジデントを務めるOmer Azariaは、GitLab Transcendでこう述べています。「私たちは板挟みの状態にあります。コードは増え、攻撃は速くなり、それでもチームの規模は変わりません」

GitLab Duoセキュリティレビューは、マージリクエストの中から認可の不備を探します。ただし、ビジネスロジックの欠陥の多くは、差分だけを見ても姿を現しません。あるエンドポイントが所有者を確認すべきかどうかは、データモデル、アプリケーションが定義するロール、そして同じレコードを扱う他のエンドポイントの挙動によって決まるからです。1つのハンドラーを判断するには、その周囲にあるアプリケーションを読む必要があります。

Business Logic Security Analyzerがリポジトリ全体をスキャンするのは、このためです。そして、それを実行する基盤としてGitLabが適しているのも、同じ理由によります。ソースコード、それをビルドするパイプライン、そこに紐づくセキュリティの検出結果、そしてそれらを制御するポリシー。これらすべてが1つのシステムの中にあります。ここでスキャンを実行するエージェントは、アプリケーションの全体像を把握したうえで、セキュリティチームが普段作業している場所に検出結果を書き込みます。

GitLabはTranscendでGitLab Security Standardを発表しました。コードは豊富にあり、信頼は不足しているという前提に立ち、各エージェントがより大きな自律性を獲得するために通過すべき5つのステージを定めたものです。そのうち「検証」のステージは、人間が書いたかエージェントが書いたかを問わず、すべての変更が作成者には手を加えられない制御を通過することを求めています。Business Logic Security Analyzerが動くのは、まさにその作成者の手が届かない場所。検出結果は、コードベースの他の部分を統制しているのと同じレポートおよびダッシュボードに残ります。

アナライザーの仕組み

Business Logic Security Analyzerは、GitLab Duo Agent Platform上の基本フローの1つで、ビジネスロジックの欠陥を対象とします。まず着手したのは、オブジェクトレベル認可の不備、認可の欠如または不適切な認可、そしてマスアサインメントの3つ。リポジトリ全体のスキャンを実行できるほか、パイプラインの通過後にマージリクエストごとの自動スキャンも実行できます。

こうした欠陥を検出するには、そのアプリケーションが本来何をするものなのかというモデルが欠かせません。パターンスキャナーはそれを持ちませんが、リポジトリを読み込むエージェントであれば自ら構築できます。アナライザーがまず行うのは、アプリケーションのエントリーポイントの列挙と、誰に何が許可されるべきかの対応づけ。どのレコードがどのユーザーに属するのか、どのアクションが管理者向けなのか、という観点から、対象範囲内の各ハンドラーを読み、レコードに触れる前にそのルールを適用しているかどうかを確認します。検出結果は脆弱性レポートとマージリクエストのセキュリティウィジェットに、SASTの結果と同等のものとして表示され、トリアージ、修正、監査に活用できます。

以下のデモアプリケーションでは、refund_orderがリクエストからorder_idを受け取り、呼び出し元がその注文の所有者であるか、あるいは管理者であるかを確認しないままrefunded=1を設定しています。クエリはパラメーター化されているため、テイントルールは何も検知しません。アナライザーはこれをapp/orders.py:17のCWE-639、深刻度Criticalとして報告し、その説明の中で所有者確認が欠落している点を指摘します。

アナライザーを支えるモデル

Business Logic Security Analyzerは、AnthropicのClaude Mythos 5.1に対応するGitLabで最初の機能であり、承認済み環境をご利用のお客様に早期アクセスとして提供されます。モデルが参照するのは、GitLabのプロンプトとお客様のリポジトリだけ。アナライザーが必要とするコンテキスト、すなわちデータモデル、ロール、そして各エンドポイントが適用するルールは、いずれもそのリポジトリの中にあります。Anthropic IndiaでHead of Applied AIを務めるRajat Pandit氏は、Transcendでこう語りました。「防御する側が攻撃する側よりも多くのコンテキストを持つとき、高度なモデルは形勢を防御側に有利なものへと変えます」

Mythosに加えて、AnthropicのClaude Opus 5.5、Sonnet 5.5、Sonnet 5、Sonnet 4.6にも対応しており、今後のリリースではさらに多くのモデルへの対応を予定しています。いずれもGitLabのAIゲートウェイを経由するGitLab管理モデルとして動作し、データの取り扱い条件もGitLab Duo Agent Platformの他の機能と変わりません。

早期アクセスのお申し込み

Business Logic Security Analyzerは現在、GitLab.comをご利用のGitLab Ultimateのお客様のうち、限られた範囲を対象とした早期アクセスの段階にあります。ご参加いただくお客様には、自社のコードベースでアナライザーを実行し、セキュリティチームがまだ把握していなかった真陽性を見つけ出していただきます。アナライザーがどこで正しく、どこで誤り、どこで沈黙するのか。GitLabは各チームと協力しながら、その検証を進めていきます。スキャンのたびにGitLabクレジットを消費し、そのコストはアプリケーションのアタックサーフェス（攻撃対象領域）の規模に応じて変動します。

ご検討をご希望の場合は、担当のアカウントチームまでご連絡ください。まだGitLabをご利用でない場合は、セールスチームへお問い合わせください。グループで機能が有効化されたら、GitLab Duo ChatまたはAPIからリポジトリ全体のスキャンを開始できます。マージリクエストをスキャンする場合は、プロジェクトにBusiness Logicのスキャンプロファイルを割り当ててください。前提条件とセットアップ手順については、Business Logic Security Analyzerのドキュメントをご覧ください。