脆弱性管理

脆弱性管理は、脆弱性の特定、優先順位付け、緩和、および修正を継続的に行うプロセスです。GitLab では、分析対象のコンポーネントに応じて、さまざまな方法で脆弱性を特定します。このプロセスと関連するツールは、脆弱性管理チームが所有しています。

このページでは、主に GitLab における脆弱性管理ポリシーと手順について説明します。GitLab で脆弱性を管理するために使用されるポリシーと手順を総称して脆弱性管理標準と呼びます。

クイックリファレンス

• Runbook: 脆弱性が見つかったらどうする？
• Runbook: 開発で脆弱性は通常どのように修正されるか？
• SLA 内に（または全く）修正できない脆弱性検出があります。どうすればよいですか？
• 脆弱性とは何か？
• なぜ脆弱性を修正すべきか？
• 脆弱性が「修正された」と見なされるのはいつか？
• 脆弱性追跡 Issue はいつクローズしてよいか？
• GitLab における脆弱性管理とは何で、彼らは何をしているのか？
• どの自動化ツールが GitLab の脆弱性管理ワークフローを実行しているか？

GitLab における脆弱性管理は何をカバーするか？

脆弱性管理は、GitLab クリティカルシステムの階層化方法論 に基づき、GitLab 本番および/または GitLab 顧客データを保存・処理・送信するすべてのシステム、および GitLab が管理するソフトウェアおよびソフトウェア依存関係をカバーします。具体的には:

• GitLab 管理のインフラ
• GitLab ソフトウェア、パッケージ、イメージ、依存関係
• 後から検出されたもの (HackerOne レポート、コミュニティまたはチームメンバーからのバグ報告、ペネトレーションテストの所見)

アプローチと戦略

GitLab の脆弱性管理は、主に脆弱性、脆弱性検出、攻撃対象領域に関するデータの収集にフォーカスしています。これは、さまざまなソースのデータを収集・正規化・関連付けし、所見に直接対応または緩和する自動化されたアクション可能なワークフローに変換するツールを構築することで行います。これが自動的に行えない場合、このプロセスの出力を、所見の緩和または修正の責任を持つ GitLab の DRI が容易に利用・理解できるようにすることを目指しています。私たちのゴールは、このツールを GitLab 自体にフィードバックし、可能な限り GitLab の機能を構築・利用して、自分たちと顧客のワークフローをサポートすることです。

スコープ

脆弱性管理チームが作業するスコープは、当面の業務に応じて変化することがあります。参考として、Security Compliance チームが定義した Technical scopes を使用しています。

脆弱性管理標準

• 可能な限り、GitLab を脆弱性検出と管理の唯一の情報源として使用すべきです。GitLab Issue は、脆弱性を修正するために必要なエンジニアリング作業に加えて、脆弱性管理活動を追跡するために現在使用されています。
• アプリケーション (WebApp およびコンテナ) の脆弱性スキャンは少なくとも月次で実施され、スキャン対象のコードに合わせて調整されたスキャナーとスキャナー設定を使用しなければなりません。これには、適切な依存関係スキャン、コンテナスキャン、シークレットスキャン、SAST スキャンジョブの有効化が含まれます。利用可能なすべてのスキャナーについては Secure your application ドキュメントを参照してください。可能な限り、サポートされている テンプレート または コンポーネント に基づき、CI 内で標準でサポートされる GitLab スキャナーを使用すべきです。
• GitLab が出荷するコンテナイメージは、出荷前に少なくとも GitLab コンテナスキャンでスキャンされなければなりません。
• インフラ (オペレーティングシステムおよびデータベース) の脆弱性スキャンは少なくとも月次で実施されなければなりません。
• インフラの外部スキャンに加えて、特権ネットワークドメインからの認証/クレデンシャル付きスキャンも可能な限り実施すべきです。
• 脆弱性スキャナーは最新（運用可能な最新バージョン）であり、不正な使用または変更に対して耐性を持つよう堅牢化されていなければなりません。
• サードパーティによるペネトレーションテストは年次で実施しなければなりません。
• 緩和されている、または悪用可能でない場合でも、脆弱性のあるコード（依存関係を含む）は、脆弱な所見を解決するために削除または非脆弱なバージョンに更新する必要があります。これは、脆弱なコードを出荷しないためです。なぜこれを行うかの詳細については、なぜ脆弱性を修正すべきか？ を参照してください。
• 例外がある場合を除き、脆弱性は SLA 期間内に修正しなければなりません。SLA 内に脆弱性が修正されない場合、責任のあるグループは、定期的なグループ開発レトロスペクティブの一部として、修正 SLA 期間を満たさなかった要因を理解するために取り組むべきです。

サービスレベルアグリーメント (SLA) / サービスレベルオブジェクティブ (SLO)

脆弱性管理 SLA / SLO に関する情報は、脆弱性管理 SLA ハンドブックページを参照してください。

ロールと責任

脆弱性トリアージに関する追加注記

1. VulnMapper は脆弱性追跡 Issue を作成し、まだ存在しない場合は適切な重大度、優先度、その他必要なラベルを追加します。Vulnmapper は現在、Issue 作成についてオプトインです。グループ用に Issue が作成されていない場合は、Vulnerability Management にお知らせください。
2. VulnMapper が自動処理できる脆弱性については、Vulnerability Management が CVSS スコア、重大度、優先度、パッケージ名、バージョンなどの必要な情報で脆弱性追跡 Issue を更新します。現在の機能は automation ハンドブックページに記載されています。
3. サポートされている OS ベースについては、VulnMapper は、ベンダーのアドバイザリとパッケージ情報に基づいて、修正の利用可能性を示すラベルも追加し、トリアージ時間をさらに削減します。この機能でサポートされている OS は限られており、automation ハンドブックページに詳細が記載されています。
4. 修正が利用できない場合や、NVD とベンダーの重大度に違いがある場合、VulnMapper はベンダー依存関係およびベンダーリスク調整のための Deviation Request Issue を自動的に報告します。
5. Vulnerability Management は、利用可能な情報に基づいて vulnerability issues を開発グループに割り当てます。VulnMapper は GitLab 開発グループのオーナーシップ情報のマップでも構成されており、Issue を更新または作成する際に、適切なトリアージグループラベルで異なるグループ向けに Issue を適切にラベル付けします。
   1. 可能な限り、Vulnerability Management は、私たちの自動化を通じて、脆弱性検出への対処方法について MR または脆弱性追跡 Issue の説明を介して推奨を行います。
   2. 脆弱性トリアージは共同責任ですが、Vulnerability Management が DRI です。AppSec、InfraSec、および各機能ドメインの開発グループは、Vulnerability Management のリクエストに応じて、脆弱性トリアージ中に GitLab 固有の影響に関する証拠および/または分析を提供する責任を持ちます。脆弱性追跡 Issue はさらなる分析のために適切な AppSec stable counterpart または開発グループに割り当てられ、その後、修正のために責任のある開発またはインフラグループがオーナーおよび DRI となります。これは彼らが影響を受ける脆弱な資産に対するコンテキストと責任を持つためです。
6. 脆弱性は、責任のあるグループによる修正の準備が整いました

連絡先

脆弱性管理に関する質問や懸念がある場合は、Slack の #g_security_vulnmgmt または #security チャネルで Vulnerability Management および Engineering に連絡してください。また、脆弱性管理 Issue トラッカー に Issue を作成 することもできます。このプロセスを改善するために行われているすべての作業も Issue トラッカーで追跡されており、フィードバックを歓迎します。

例外

脆弱性を緩和または対処していて、GitLab の脆弱性管理標準を満たせないと考えている場合は、例外リクエストを提出してください。例外リクエスト、対応、SLA 例外リクエストの提出を含む詳細については、SLA 例外ハンドブックページ を参照してください。

参考資料

• Application Vulnerability Management Procedure
• バグ報奨金

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