Content last updated 2026-03-12

セキュリティダッシュボードレビュー

頻度: 毎日

AppSec エンジニアは GitLab セキュリティツールの検出結果をトリアージする責任があります。この役割には主に 2 つの機能があります。

  1. 検出結果を検証し、修正のためにエンジニアリングに引き継ぐ
  2. Secure チームにフィードバックを提供する

セキュリティダッシュボード一覧

レビューが必要なセキュリティダッシュボードのリストは以下のとおりです:

検証

各検出結果について:

  • 提供された情報と追加情報を使って、検出結果が有効かどうかを判断します
  • 有効なレポートの場合:
    • ステータスを Confirmed に変更します
    • Create Issue をクリックします
    • 検出結果の評価および GitLab への影響に基づいて優先度と重大度ラベルを割り当てます
    • 期日を割り当てます
    • DevOps ステージとソースグループに対応するラベル（/label ~ コマンド）を追加します（カテゴリーが構成する階層の概要については階層を参照）
    • プロダクトカテゴリーページに基づき、トリアージを完了するために追加のエンジニアリングフィードバックが必要な場合は、適切なチームのプロダクトマネージャーやエンジニアリングマネージャーをスケジューリングのために @ メンションします
      • 適切なエンジニアリングチームがすぐに明らかでない場合は、所有者を特定するために AppSec マネージャーにピンを送ってください
  • 無効なレポートの場合:
    • ステータスを Dismissed に変更します
    • 脆弱性が却下された理由についてのフィードバックを含むコメントを残します。この情報は Secure エンジニアがツールの検出結果のチューニングに使用でき、将来なぜ却下されたか疑問が生じた場合にも有用です。

依存関係の更新

製品の依存関係に脆弱性が特定された場合、AppSec エンジニアはセキュリティ開発ワークフローに従って、サポートされているすべてのバージョンで依存関係を更新するためのマージリクエストを作成すべきです。マージリクエストは GitLab Security リポジトリ で開かれるべきで、これによりサポートされているバックポートでも依存関係が更新されます。Critical または High と判断された脆弱性については、特定された時点でマージリクエストを作成すべきです。Medium および Low の脆弱性はベストエフォートで対応しますが、必ず 90 日の SLA 内に対応します。

このプロセスの目標は、依存関係をできるだけ早く更新し、マイナーアップデートに対する開発チームへの影響を減らすことです。将来的にこのステップは 自動修復 に置き換えられる可能性があります。

新しいメジャーバージョンへのアップグレードが必要な場合、責任ある開発チームが直接対応することが必要になる場合があります。

  • 上記の検証プロセスを完了します。
  • Security developer workflow テンプレートを使用して、GitLab Security リポジトリ Issue トラッカーで Issue を作成します。
  • テンプレートに従って、master ブランチをターゲットとするマージリクエストを作成します。
  • 結果として得られるパイプラインがクリーンな場合、マージの準備として開発者チェックリストを継続します。これにはレビュアーとメンテナーによるレビューが含まれている必要があります。
  • パイプラインが失敗した場合、責任ある開発チームと協力して修復します。原因によっては、依存関係の機能に高度な知識を持つ開発者が変更をレビューする必要がある場合もあります。開発者がすぐに対応できない場合は、定義された SLA 内での修復を確実にするために Issue/MR を追跡し続けます。
最終更新 June 14, 2026: Merge pull request #403 from kyama0/claude/cool-turing-ls6eck (bfd74782)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License