Vulnerability Management チーム

このハンドブックページでは、Vulnerability Management チームが日々、四半期ごとにどのように作業しているかを説明します。 私たちは、このプロセスがイテレーション的であり、常に改善し停滞しないために定期的な内省が必要であると認識しています。

ミッション

Vulnerability Management チームは、セキュリティ脆弱性に対する包括的な可視性を提供し、自動化されたワークフロー、標準化されたプロセス、明確なリスクコミュニケーションを通じて効率的な修復を推進することで、GitLab がお客様にセキュアなソフトウェアを出荷できるようにします。私たちのチームは、GitLab の進化するテクノロジー環境全体にわたって、チームがセキュリティリスクをプロアクティブに管理できるようにする脆弱性インテリジェンス、ツール、メトリクスの中心的なハブとして機能します。

価値提案

私たちは、自動化された脆弱性検出、標準化された修復ワークフロー、包括的なリスク可視性を提供することで、ステークホルダーとお客様が開発のスピードを維持しながらコンプライアンス要件を満たし、自信を持って GitLab を構築・デプロイできるようにします。

スコープと責任

主要なオーナーシップ領域

脆弱性管理の標準と手順

• 脆弱性管理ポリシーの確立と維持
• SLA フレームワークと修復期限の定義
• 例外およびリスク受容プロセスの作成
• スキャン要件とカバレッジ基準の設定

脆弱性検出と相関

• VulnMapper の開発と維持
• 複数の脆弱性データソースとの統合
• 脆弱性 finding の正規化
• Advisory データの管理と相関

自動化されたワークフロー管理

• 脆弱性追跡 Issue の作成とルーティング
• 例外申請の取り扱い

プログラムカバレッジと可視性

• インフラ脆弱性スキャン（GitLab.com、Dedicated）
• コンテナと依存関係のスキャンインベントリとスキャンカバレッジ

プログラムメトリクスとレポート

• ステークホルダースコープのリスクコミュニケーション（後述のメトリクス参照）
• お客様向けアーティファクトの生成
• コンプライアンス監査の証拠収集のサポート

効率的な修復のサポート

• 修復への課題の特定と文書化
• 修復ワークフローの自動化
• ドキュメンテーションの提供

FedRAMP

• 脆弱性スキャンツール
• 脆弱性アーティファクトの自動生成

共有責任

脆弱性トリアージ

脆弱性トリアージモデルは、専門知識とドメイン知識に基づいてチーム間に分散されています。このアプローチにより、脆弱性評価の効率と正確性が向上します。

• Vulnerability Management

  • すべての脆弱性に対する自動化されたコンテキスト充実の提供
  • パッチ可用性情報とベンダートリアージステータスの提供
  • Advisory データソースとの統合の維持
  • 一貫したラベリングとワークフロールーティングの確保

• PSIRT

  • HackerOne レポートとバグバウンティ提出物のトリアージ
  • アプリケーション脆弱性の悪用可能性と影響の評価

• Infrastructure Security

  • クラウド／インフラの誤設定のトリアージ
  • Wiz クラウドセキュリティアラートの検証
  • インフラ修復の優先順位付け

• Engineering

  • アプリケーションコンポーネントに関連する GitLab ツールの finding のトリアージ
  • 脆弱性リスク評価のためのビジネスコンテキストの提供
  • 修復アプローチの技術的実現可能性の評価
  • コードベース内の依存関係脆弱性の検証

• エンゲージメントモデル

  • 脆弱性の深刻度によって定義されるトリアージ SLA
  • GitLab Issue を通じて調整されるクロスチームコラボレーション
  • VulnMapper を通じた自動化されたトリアージワークフロー

スコープ外

直接的な脆弱性修復

Engineering／Infrastructure によって所有されるタスク:

• 脆弱性に対するコード修正の作成
• パッチのデプロイ
• インフラ変更の実施
• 直接的なシステム変更

ユーザーエンドポイントに関連する脆弱性

CorpSec によって所有されます

• エンドユーザーシステムの資産管理
• エンドユーザーシステム上のパッチ追跡と測定
• エンドユーザーシステムの脆弱性の報告

GitLab プラットフォーム機能の開発

• お客様が使用する GitLab Security Dashboard / Report 機能
• CI/CD 脆弱性スキャンツールの開発／維持
• GitLab advisory データベース
• 機能に応じて Sec section のさまざまなチームによって所有されます。

お問い合わせ

Slack

• #security_help - 質問とフォローチームのコミュニケーション用の公開セキュリティチャネル
• @vulnerability-management - Slack グループハンドル

GitLab

• @gitlab-com/gl-security/product-security/vulnerability-management

FY26 戦略的イニシアチブ

• データを起点としたリーディング
• 統合された脆弱性ライフサイクル
• FedRAMP

プランニング

Vulnerability Management は GitLab の 製品マイルストーン に従います

新しいマイルストーンが始まる前に、次のマイルストーンの期待される成果と、それを達成するために必要な作業を定義するためのプランニングが行われます。マイルストーン内でこの作業を提供する能力を確認し、フィットするように Issue にコミット／調整します。さらに、スコープが定義されていないかサイズが定められていない作業は、認定されラベル付けされます。

四半期項目を適切なサイズの作業項目（Issue）にどのように分解するか？

理想的には、新しい Issue が作成されたときにサイジングとプランニングのラベルが追加されます。私たちは、作業をマイルストーンに合わせて並列化できるように、小さな実行可能な Issue として作業を定義することを目指します。作業がサイジングとスコープ定義されていない場合、そのマイルストーンにスケジュールしたい項目について、マイルストーンプランニング中にこのサイジングとスコープ定義の作業を行います。

リファインメントとサイジング

作業は、定義されたタスクを完了するために必要なマイルストーンの推定割合に基づいてサイジングされます。作業はできる限り明確に定義され、誤解された要件によるスコープクリープの影響を最小限に抑えるよう試みます。Issue サイジングは、Issue ウェイトとサイジングラベルの定義されたスケールで実行されます。

これらのステップはガイドラインとして使用されます:

1. 望ましい結果を達成するために必要な十分に詳細な要件について Issue を確認します。
2. 要件または出力が、Issue が実行可能であるか、マイルストーンのどれだけを消費するかを自信を持って評価するのに十分明確でない場合、リファインメントが必要です。
3. 文書化された出力を調査、研究、提供するための推定時間に基づいて、Issue に適切なウェイトとラベルを追加します。
4. 可能であれば、プランニング中にクロスチームコラボレーションが必要な Issue について他者の助けを要請します。

Issue の重み付け

これは、スケジューリングのために Issue をサイジングするために使われるスケールです。注意: 推定期間は、スケジューリング期間ではなく、全体的な労力を指しています。例えば、大きなタスクをいくつかの小さなタスクに作成して並列化できる場合、4 週間以上のスケジュールされた時間より短く完了することがありますが、それでも大きな作業項目として適切にサイジングされます。

Issue は、必要とされる予想される労力レベルを記述するために development label でラベル付けされるべきです。

使われている追加のラベル

前のセクションで詳述されたサイジングラベルに加えて、優先順位付けとプランニングに次のラベルが使われます。

ページのソースコードを見る - ページの編集 - please contribute.