更新日:2026年7月17日

5分で読めます

GitLab Duoセキュリティレビューでスキャナーが見逃すロジックの欠陥を検出

AIによるセキュリティ推論で、コードレビューの段階のうちに認可の不備やビジネスロジックのエラー、レース条件を検出します。

静的スキャナーは、サニタイズされていないクエリ入力やハードコードされたシークレット、安全でないデシリアライゼーションのような、既知のパターンに当てはまる脆弱性の検出を得意としています。一方で、アプリケーションのロジックに潜む欠陥には弱く、そこには一致させるパターンは存在しません。あるのはただ、ドメインの文脈では誤った動作をする、構文的には正しいコードだけです。こうした欠陥は検出されないまま後工程で表面化し、修正コストを押し上げます。

パブリックベータ版として提供が始まったセキュリティレビューフローは、セキュリティエンジニアと同じ視点でコードの変更を精査します。シグネチャの一致ではなく意図を読み取ることで、ロジックの欠陥を本番環境に到達する前に捉えます。スキャナーが見逃しがちな危険な欠陥を発見するための、大きな一歩です。

パターンベーススキャナーの盲点

アプリケーションに最も大きな被害をもたらす脆弱性は、多くの場合、1行ずつ見れば正しいコードでありながら、認可モデルやデータの機密区分、意図されたワークフローといった、コード自体には含まれない文脈に違反しています。ここでは、代表的な3つの脆弱性クラスを見ていきましょう。

アクセスと認可: ユーザーがリソースを読み取ったり変更したりできるかどうかは、言語仕様ではなく認可モデルによって定義されます。オブジェクトレベル認可の不備(IDを変更するだけで他ユーザーのデータにアクセスできてしまう問題)は、2019年以降OWASP API Security Top 10で常に上位を占めています。

データの露出: オブジェクトをシリアライズして返す処理自体は、ごく普通の、一見正しいコードです。それが情報漏えいになるかどうかは、どのフィールドが機密で誰がそれを受け取るかという、構文ではなくドメインの事実によって決まります。

制御フローとワークフロー: ビジネスロジックやレース条件に起因する欠陥は、有効な操作が誤った順序で実行されたり、想定外に繰り返されたり、操作されたりすることで発生します。例えば、支払いなしでチェックアウトに到達できてしまう、競合状態で同じ状態に再突入してしまう、パラメーターを改ざんして価格を変更してしまう、といったケースが挙げられます。

こうした欠陥を捉えるには、これまで手動でのセキュリティレビューが必要でした。しかし、これをすべてのマージリクエスト(MR)に対してスケールさせるにはコストがかかります。また、ペネトレーションテストやバグバウンティは有効な手段ですが、実施のタイミングが遅すぎます。その結果、開発のスピードとセキュリティの専門知識を適用できる速さとの間で、ギャップが広がり続けています。

すべてのMRにセキュリティの判断を

GitLab Duo Agent Platformの基本フローであるセキュリティレビューフローは、コードが本来何をすべきかを推論することで、このギャップを埋めます。上述した脆弱性クラスを的確に検出します。具体的には、オブジェクトレベルおよび機能レベルの認可の不備、状態変更操作における認可の欠如、情報開示、マスアサインメント、ビジネスロジックのエラー、そしてステートフルなワークフローにおけるレース条件です。

従来のスキャナーや人間による分析を置き換えるのではなく補完するものであり、修正コストが最も低い変更の時点でコードをレビューします。GitLab自身のアプリケーションセキュリティチームも、開発期間を通じて社内のMR全体でセキュリティレビューフローを活用してきました。

セキュリティレビューフローの実際の動作を見る:

仕組み

MRの準備が整ったら、人にレビューを依頼するのと同じ要領でDuo Security Reviewにレビューを依頼します。元のファイル、変更された行、MRでの議論、関連コードといった文脈の中で差分を解析します。その推論は精度を重視して最適化されており、さらに独立した検証パスが各所見を確認し、誤検出の可能性が高いものを除外します。

検出結果は、該当する行への差分スレッドとして表示されるほか、内部ノートにも要約が記載されます。パブリックプロジェクトでは、内部ノートのみに限定されるため、セキュリティの詳細が外部に露出することはありません。

各所見には、レビュアーに必要な次のような文脈が付与されます。

  • 脆弱性の種類(CWE参照付き)
  • 重大度:Critical、High、Medium、Low のいずれか
  • ティア:Tier 1(悪用可能)、Tier 2(ロジックの欠陥)、Tier 3(設計上の問題)のいずれか
  • 問題の平易な説明
  • 修正案(利用可能な場合)

重大度によってレビュアーの状態が決まります。CriticalまたはHighの所見があった場合は変更をリクエストに、MediumまたはLowの所見の場合はコメントになります。何も検出されなかった場合でも、このフローが承認することはありません。最終判断は常に人間が担います。

その後は、コメントスレッドで組織のDuo Security Reviewサービスアカウントにメンションすることで、質問したり、修正方法を議論したり、所見に異議を唱えたりできます。各所見は、通常のMR提案として修正を適用する、誤検出として却下する、リスクを許容する、のいずれかの方法で解決します。修正をコミットしたら、変更内容を確認するために改めてレビューを依頼してください。

セキュリティレビューフローを始める

セキュリティレビューフローは、GitLab Ultimateのお客様向けにパブリックベータ版として提供されています。GitLab.com、GitLab Self-Managed、GitLab Dedicatedでご利用いただけます。

詳しい始め方は、セキュリティレビューフローのドキュメントをご覧ください。

GitLab Duo Agent Platformの無料トライアルから、セキュリティレビューフローをご利用いただけます。すでにGitLab Ultimateをご契約中の方は、Duo Agent Platformを有効にしてサブスクリプションに含まれるGitLabクレジットをご利用ください。

コストは差分の複雑さや選択するモデルによって変動するため、本格的に展開する前にいくつかのMRで試してみることをおすすめします。価格は一般提供(GA)時に変更される場合があります。

気づいた点があれば、ぜひフィードバック用のイシューで共有してください。

ご意見をお寄せください

このブログ記事を楽しんでいただけましたか?ご質問やフィードバックがあればお知らせください。GitLabコミュニティフォーラムで新しいトピックを作成してあなたの声を届けましょう。

フィードバックを共有する

今すぐ開発をスピードアップ

DevSecOpsに特化したインテリジェントオーケストレーションプラットフォームで実現できることをご確認ください。