Content last updated 2026-05-22

Automated MR Security Reviewer

GitLab のマージリクエストに対する AppSec の自動セキュリティレビューフローの使い方

Automated MR Security Reviewer は、AI 駆動のアプリケーションセキュリティレビューフローで、マージリクエストを解析して悪用可能な脆弱性、ロジック上の欠陥、設計上の問題を検出します。トリガーされると自律的に実行され、発見事項を MR の内部ノートとして投稿します。レビューの開始や完了に AppSec エンジニアが介在する必要はありません。

このフローは現在、gitlab-org/gitlab および一部の選定されたプロジェクトのマージリクエストで利用可能です。AppSec チームは、このフローがより広範なロールアウトを支える品質と信頼性で、一貫した低偽陽性の発見事項を生み出すかを評価中です。

このフローのソースおよび完全な技術リファレンスは appsec-security-mr-reviewer プロジェクト で管理されています。

このフローを自分のプロジェクトで有効化したい場合は、appsec-security-mr-reviewer プロジェクト に MR を提出し、flow.yaml ファイルに自分のプロジェクトを追加してください。

どのように機能するか

レビューは以下の 4 つのステップで実行されます。

  1. Build Context — MR のメタデータ、差分、コメント、リンクされた Issue、エピックを収集し、変更の全範囲を把握します。
  2. Prescan Codebase — 対象プロジェクトをスキャンして既存のセキュリティパターン(入力検証、認証、サニタイゼーション、エラーハンドリング)を特定し、プロジェクトがセキュリティをどう扱っているかのベースラインを確立します。
  3. Perform AppSec Review — AI セキュリティエンジニアがコード変更をベースラインに照らしてレビューし、悪用可能な脆弱性、ロジック上の欠陥、設計上の問題を探します。新しいコードが既存の規約を破ったり、利用可能なセキュリティユーティリティを迂回している箇所をハイライトします。
  4. Validate Findings & Post Review — 二次検証パスが偽陽性をフィルタリングし、各発見事項が文脈上で本当に悪用可能かを確認します。最終的なレビューは MR の内部ノートとして投稿されます。

このフローは、SAST ツールが既にカバーする一般的な制御漏れではなく、現実に悪用可能なセキュリティリスクに焦点を当てます。

レビューのトリガー

@mention による手動トリガー

MR のパブリックコメントでサービスアカウントをメンションすることでレビューをトリガーできます:

@ai-appsec-security-mr-reviewer-<namespace> please review this MR for security issues

サービスアカウントのユーザー名は @ai-appsec-security-mr-reviewer-<namespace> のパターンに従い、<namespace> はフローがデプロイされている GitLab グループに対応します。

トリガーされると、フローは直ちに MR に ~security-mr-reviewer-flow-triggered ラベルを付与し、実行中のジョブへのリンクを含む確認コメントを投稿します。

注: 誤った <namespace> を使用するとフローはトリガーされません。@ai-appsec.... の入力を開始すると、正しいサービスアカウントの完全名を含むドロップダウンが表示されるはずです。サービスアカウントがドロップダウンに表示されない場合、作業中のプロジェクトにフローを追加する必要があります。

CI による自動トリガー

このフローはプロジェクトの CI パイプラインに統合でき、新規 MR パイプラインで自動的にトリガーされるようにできます。仕組みは、パイプラインに代わって @mention を投稿する CI ジョブです。これにはユーザーアカウントに紐づく fine grained access token が必要です。正しい挙動のために必要な唯一の条件は、MR に ~AppSecMRReviewPerformedBy::AutomatedFlow または ~security-mr-reviewer-flow-triggered が既に付与されている場合、ジョブがメンションを投稿してはならないということです。これは、完了済みまたは進行中のレビューが二重にトリガーされるのを防ぎます。

他のすべての rules: 条件 — パイプラインソース、イベントタイプ、フォークチェック、ドラフト除外 — は設定可能で、プロジェクトのパイプライン構造に合わせて適応すべきです。リファレンスの CI スニペット、必要なトークン設定、サービスアカウントの命名については プロジェクト README を参照してください。

結果の理解

レビューは MR の内部ノートとして投稿され、発見事項はインパクトカテゴリ別にグループ化されます:Exploitable、Logic Flaw、Design Issue。各発見事項には関連するファイルパスと行番号、コードベースの他の部分で prescan が見つけたパターンに基づく根拠が含まれます。

発見事項を読む際は、以下の点に留意してください。

  • すべての発見事項を検証してください。 このフローは偽陽性を生み出す可能性があります — 一見有効に見えても、後処理のリダクション、キャッシング動作、フレームワークレベルの保護といった広い文脈を見落としていることもあります。対処する前に、必ず自分のコード知識と照らし合わせて確認してください。
  • 発見事項がないことも有効な結果です。 MR がクリーンなときに、フローが問題を捏造することはありません。
  • セキュリティ以外の観察は付随的なものです。 フローがセキュリティ上の懸念ではない事項を提示した場合、このチャネルを通じて対処しないでください。

レビューの再トリガー

コード変更後に新規レビューを依頼するには、最初に使ったトリガー方法を繰り返します。

CI ベースの設定の場合、~AppSecMRReviewPerformedBy::AutomatedFlow ラベルを削除し、新しいコミットをプッシュするかパイプラインを再実行してください。CI ジョブが rules: を再評価し、新しいメンションを自動的に投稿します。

手動の @mention の場合、サービスアカウントを新しいパブリックコメントで再度メンションするだけです。

フロー失敗とリカバリ

スタックまたは失敗したフローの認識

このフローは実行開始時に MR に ~security-mr-reviewer-flow-triggered ラベルを付与し、正常に完了した場合のみそれを削除して ~AppSecMRReviewPerformedBy::AutomatedFlow に置き換えます。フローが実行中にクラッシュしたりハングした場合、MR には ~security-mr-reviewer-flow-triggered が残ります — このラベルはクリーンアップされるまで CI ベースおよび手動の再トリガーの両方をブロックします。

実行が失敗または停止しているサイン:

  • ~security-mr-reviewer-flow-triggered が存在するが、~15〜20 分経過してもレビューノートが表示されない。
  • 確認コメントにリンクされたジョブが CI でスタックしているかエラーを示している。

リカバリ手順

  1. ジョブログを確認する。 フローの確認コメントにリンクされた CI ジョブを開き、エラーメッセージやジョブが停止したステップを探してください。

  2. AppSec チームに通知する。 ジョブの URL、エラー出力、観察した内容の説明とともに、MR の新しいノートで @appsec をタグ付けしてください。

  3. ブロッキングラベルを削除する。 MR から ~security-mr-reviewer-flow-triggered を削除します。MR にアクセスできる人なら誰でも、ラベルサイドバー経由でこれを行えます — 特別な権限は不要です。

  4. 再トリガーする。 ラベルがクリアされたら、該当するトリガー方法(CI パイプラインの再実行または新しい @mention)を使用してください。

既知の制限

PoC で以下の制限が確認されています。いずれも修正タイムラインはコミットされていません。

オープンな議論スレッドがマージボタンをブロックする。 フローの確認コメント("✅ AppSec Security MR Reviewer has started")は MR 上のスレッドを開きます。GitLab はマージ前にすべてのスレッドを解決することを要求していますが、フローはスレッドを自動的にクローズできません。レビュー完了後に手動で解決してください。

すべての発見事項が単一のノートに表示される。 このフローは発見事項ごとに個別の議論スレッドを作成するのではなく、1 つの統合された内部ノートを投稿します。これにより、どの発見事項が対処済みかを追跡するのが困難になります。発見事項を個別のスレッドに分割することは、将来のイテレーションで検討されています。

まれにハルシネーションが発生する。 LLM は、コードベースに存在しないコード構造や挙動を参照する発見事項を生成することがあります。常に実際のコードに対して検証してください。ハルシネーションは下記のフィードバックプロセスで報告してください。

重複レビュー。 まれにフローが同じ MR で 2 回実行され、2 つのレビューノートを生成することがあります。CI ジョブに retry: が設定されている場合は削除してください — @mention POST はべき等ではなく、リトライは重複実行をトリガーします。リトライ設定の変更なしに重複が発生した場合は AppSec チームに報告し、最新のノートを使用してください。

フィードバックの提供

フローを使用するエンジニアからのフィードバックは、AppSec チームによるキャリブレーションと改善に直接影響します。MR にレビューが投稿された後:

フィードバックラベルを適用する:

  • ~"appsec-flow-mr-review::helpful" — レビューが現実の問題や有用なコンテキストを特定した場合
  • ~"appsec-flow-mr-review::unhelpful" — レビューが有用でなかったか、偽陽性を生成した場合
  • ~"appsec-flow-mr-review::mixed-helpful" — レビューが有効と無効な発見事項の両方を生成した場合
  • ~"appsec-flow-mr-review::non-security-helpful" — レビューが有効だがセキュリティに関係のない発見事項を生成した場合

フィードバック Issue にコメントを残す — MR へのリンクと、フローが正しく捉えたこと、間違って捉えたこと、品質改善に役立つその他の詳細を記載してください。

利用状況の追跡はこれらのラベルが適用されていることに依存しています。ラベルのない MR はフローの利用データに表示されません。