Content last updated 2026-04-09

脆弱性解決 SLA

[TOC]

脆弱性管理 SLA とラベル

以下の期限またはサービスレベル合意（SLA）は、規制コンプライアンス、顧客 SLO・SLA、脆弱性の影響、範囲、GitLab 環境での蔓延度、悪用された場合の影響、GitLab とお客様を守るための合理的な緩和・修復のターンアラウンドタイムの定義など、多くの要因に基づいています。これらすべての要因が、優先度を GitLab の優先度ラベル にマッピングする際に考慮されます。脆弱性管理の対象範囲にあるすべてのコンポーネントは同じ SLA に従います。SLA は次のとおりです:

CVSSv3 スコア*深刻度優先度緩和までの時間修復までの時間 (TTR)
9.0-10.0 (Critical)~severity::1~priority::124 時間以内30 日 SLA
7.0-8.9 (High)~severity::2~priority::2N/A30 日 SLA
4.0-6.9 (Medium)~severity::3~priority::3N/A90 日 SLA
0.1-3.9 (Low)~severity::4~priority::4N/A180 日 SLA

* 脆弱性の深刻度は、次のリストから最初に利用可能な値を使って割り当てられます:

  1. CVSSv3 ベーススコア。
  2. CVSSv2 ベーススコア。
  3. 脆弱性スキャナによって報告されたベースリスクスコア。

影響を受けるデプロイ方法に対して修正が利用可能になった時点で、脆弱性は修復されたとみなされます。これには通常、修正をすべての SaaS 環境に公開すること、および修正を含む新しい self-managed リリースが行われることが含まれます。

定義

SLA（Service Level Agreement）または SLO（Service Level Objective）とは何か？

SLA と SLO はどちらも多義的な用語であり、通常は特定の結果が保証される（SLA）、または目標とされる（SLO）期限を指します。これらの用語はインシデント管理、顧客契約、コンプライアンスフレームワーク、セキュリティなどさまざまな文脈で使われ、GitLab の脆弱性管理 SLA も結果として他の SLA（FedRAMP の脆弱性修復 SLA など）への入力となることがしばしばあります。

GitLab における脆弱性管理の文脈では、SLA と SLO（Service Level Objective）という用語は同じ意味で使えます。脆弱性が修復対象とされる期限を Service Level Agreements（SLA）と呼びます。GitLab における脆弱性管理の文脈では、これらの SLA は GitLab のチームメンバーとグループ間のものであり、脆弱性検出から修復・修正提供までの時間を追跡します。

脆弱性修復 SLA とは何か？

GitLab では、ソフトウェアおよびシステムの脆弱性を特定の時間制限内に解決することを約束しています。通常、これらの制限は、時間制限がサードパーティと契約上合意されているかどうかに応じて、それぞれ脆弱性修復 SLA（Service Level Agreement）または SLO（Service Level Objective）と呼ばれます。ほとんどの場合、私たちの修復目標は objective ですが、シンプルさと一貫性を保つために SLA という用語を使用します。

脆弱性修復 SLA はなぜ重要か？

修復 SLA は、脆弱性の重大性と予想される影響に基づいて、GitLab ユーザーとお客様がセキュリティ脆弱性をどのくらい迅速に緩和されると期待できるかについて、合理的な期待を設定します。脆弱性とそれに対処するために必要な作業には緩和のための作業が必要であり、すべての作業と同様に優先順位付けが必要です。深刻度・影響度ベースの SLA は、私たちの製品、システム、ひいてはお客様とユーザーのセキュリティに最もポジティブな影響を提供しながら、この作業に優先順位を付ける最もシンプルな方法です。

責任ある開示 vs SLA

GitLab のセキュリティ問題に対する修正をリリースして公開する際、当然 GitLab のセキュリティ脆弱性の性質を開示することになります。この情報は、これらの脆弱性を悪用しようとする者にとって有用です。このため、GitLab の脆弱性の公開開示前に、特定の脆弱性が GitLab.com で修正されることを保証しています。この状況において、SLA にはリリースを行い GitLab.com にデプロイするのに必要な時間が含まれます。

GitLab.com に修正をデプロイするために使用される期限、基準、手順についての詳細は、リリースプロセスドキュメンテーションプロジェクト のセキュリティセクションで利用可能です。

他の環境については、可能な限り、GitLab の脆弱性が脆弱性と修正の公開開示前にパッチが当てられリリースされるようにすることで、このガイダンスを順守する最善の努力を行うべきです。

このポリシーに対する例外は、合意された顧客のメンテナンスウィンドウなど、他の顧客への約束や契約上の義務が修正のデプロイの必要性を上回る場合に発生する可能性があります。クリティカルな脆弱性については、これらの脆弱性が公開開示前に適用されるように緊急メンテナンスを追求すべきです。その他の脆弱性については、公開開示前に修正をデプロイするための最善の努力を行うべきです。

SLA は何を測定するか？

セキュリティ脆弱性の文脈における SLA は、脆弱性を解決または緩和するのにかかる時間を測定します。解決と緩和の定義は、脆弱性、それが検出された場所、および影響を受ける GitLab 資産の可用性または安定性に影響を与えずに現実的に対処できるかどうかに基づいて異なります。修正済みの要件と定義は、たとえばコード内の脆弱性、サーバー上のインストール済みソフトウェアの脆弱性、またはコンテナにバンドルされたコードに対して当然異なります。これらすべての種類の資産およびそれらに影響を与える脆弱性は、SLA を適用するためには次のすべてを共通点として持っていなければなりません:

  1. すべての脆弱性が修正可能であること
  2. すべての脆弱性が検出可能であること
  3. GitLab が脆弱性によって影響を受ける資産について責任を負うこと

例えば、私たちが責任を負わないコンポーネントや資産には SLA を適用できません。なぜなら、特定の期限内に脆弱性に対処するための約束や計画を立てることができないからです。

私たちがバンドルする依存関係（コードやイメージ内）またはインストールする依存関係（責任を負うシステム上）の場合、私たちは脆弱性に対処する更新をデプロイする責任を負うため、更新が実際に利用可能になった時点で SLA が関連します。GitLab が責任を負うシステムの構成または GitLab が責任を負うコード内の脆弱性については、私たちが直接責任を負い、緩和または修復が利用可能になる時期に関係なく SLA が適用されます。なぜなら、脆弱性の全体的な修復の一環として、脆弱性に対する緩和または修復を定義することにも責任があるからです。

GitLab が直接責任を負うコードまたはイメージ（つまり依存関係ではないもの）に脆弱性が存在する場合、SLA は脆弱性の最初の検出から、修復が GitLab ユーザーとお客様に一般的に利用可能になるまでの時間を測定します。

GitLab が責任を負うシステム上のコード依存関係、イメージコンポーネント、またはパッケージ（GitLab が提供するイメージとパッケージの GitLab 管理システムへのインストールを含む）に脆弱性が存在する場合、SLA は更新されたパッケージまたはイメージが利用可能になってから、更新されたイメージまたはパッケージが影響を受けるシステムにデプロイされるまでの時間を測定します。管理システムの文脈では、SLA は具体的にはシステムごとの最初の検出から解決までの時間を測定するため、SLA を測定するためにはシステムごと・脆弱性ごとに追跡する必要があります。

GitLab が責任を負うコードまたはイメージ（GitLab のデプロイに使用されるサポート対象イメージやパッケージなど）に脆弱性が存在し、それが GitLab がお客様の代わりに管理するシステム（GitLab Dedicated など）にデプロイされる場合、管理環境にデプロイされる GitLab コード、パッケージ、イメージ内での当初の脆弱性緩和と解決の SLA には、修正済みパッケージを管理環境にデプロイするのにかかる時間は含まれません。これは、それらの環境を管理するチームにパッチが利用可能になった時点から始まる別個の SLA とみなされます。これは、GitLab の脆弱性を責任ある形で開示する義務を置き換えるものではないため、セキュリティリリースプロセスドキュメンテーション を必ず順守してください。これについての詳細は 責任ある開示 vs SLA セクションにあります。

SLA 定義

異なる期限を持つ別個の SLA があります:

  • GitLab のコードまたはイメージ内の脆弱性に対処する修正済みパッケージとイメージをリリースするための SLA
  • 新しくリリースされたパッケージを取り入れるための SLA
  • GitLab がお客様の代わりに管理する環境に修正済みパッケージとイメージをデプロイするための SLA。

GitLab のコードまたはイメージ内の検出を緩和・修復する SLA は、GitLab のコードまたはイメージ内の脆弱性の検出または報告時に開始し、更新済みのパッケージまたはイメージが GitLab がお客様の代わりに管理する環境を担当する GitLab チームメンバーに利用可能になった時点で終了します。それらの管理環境内の脆弱性を修復する SLA は、修正済みパッケージとイメージが利用可能になった時点で開始し、パッケージまたはイメージが管理環境にデプロイされた時点で終了します。この区別は、管理環境の可用性と安定性に対する GitLab のコミットメントを維持するために行われています。

GitLab のコード、イメージ、システムにおける異なる脆弱性の典型的に異なる影響を考慮すると、影響、ひいては SLA は、明確な既知の脆弱性によって影響を受ける異なるパッケージとコンポーネント間で同じ脆弱性であっても異なる場合があります。SLA はイメージごとまたはシステムごとのレベルに加えて、コンポーネント／パッケージのレベルでも追跡される必要があり、これにより影響が正確に追跡され、SLA が正確に測定されることが確保されます。

SLA 計算方法

概要

SLA 遵守をどのように計算するかを理解することは、私たちの脆弱性修復パフォーマンスを正確に測定するために重要です。このセクションでは、脆弱性が SLA 内にクローズされたかどうかを判断するために使用される計算式と方法について説明します。

データ要件

SLA 遵守を正確に計算するためには、各脆弱性について次のデータポイントが利用可能でなければなりません:

  1. 脆弱性の最初の検出日 - 脆弱性が最初に特定された日付
  2. 脆弱性の深刻度 - 適用される TTR を決定する深刻度レベル（Critical、High、Medium、Low）
  3. 脆弱性の状態 - 脆弱性の現在の状態（例: 検出済み、解決済み、却下）
  4. 深刻度ごとの SLA Time to Remediate (TTR) - 深刻度に基づく目標修復期間（上記表参照）
  5. 修正が利用可能になった日付 - 脆弱性に対する修正がベンダーによって利用可能になった日付
  6. SLA 例外による SLA 延長期間 - 標準的な SLA 期間に対する承認済みの延長

SLA 計算式

SLA 開始日

SLA タイマーは、次の 2 つの日付のうち遅い方から始まります:

  • 脆弱性の最初の検出日、または
  • 修正が利用可能になった日付

これにより、修復が実際に可能な時間のみを測定するようにします。GitLab コード内の脆弱性については、これらの日付はベンダー脆弱性と非ベンダー脆弱性の間で異なる可能性があります。例: Ubuntu OS パッケージ更新と HackerOne で報告された脆弱性。サードパーティ依存関係については、SLA はアップストリームの修正が利用可能になった時点で開始します。

SLA 期日

SLA 期日は次のように計算されます:

SLA 期日 = SLA 開始日 + SLA TTR + SLA 延長期間

ここで:

  • SLA TTR は深刻度に基づく修復までの時間（30、90、または 180 日）
  • SLA 延長期間 は SLA 例外からの承認済み延長時間の合計（例外が適用されない場合は 0）

SLA 遵守メトリクス

クローズされた脆弱性に対する SLA 遵守率は次のように計算されます:

SLA 遵守率 % = (SLA 期日前にクローズされた脆弱性の数 / クローズされたすべての脆弱性の数) × 100

脆弱性は次の場合「SLA 内にクローズ」と見なされます:

  • 脆弱性の状態が「resolved」または同等の最終状態に変更された場合
  • 解決日が SLA 期日以前である場合

SLA を過ぎたオープン脆弱性に対する SLA 遵守率は次のように計算されます:

SLA を過ぎたオープン率 % = (count(今日の日付 > SLA 期日であるオープン脆弱性) / count(すべてのオープン脆弱性)) * 100

主要な原則

  1. 修正の利用可能性が SLA 開始を決定する - 依存関係については、アップストリームのメンテナから修正が利用可能になるまで修復できません
  2. 延長は加算的 - 複数の承認済み SLA 例外は期日を累積的に延長できます
  3. 脆弱性ごとの追跡 - SLA は正確な測定を確実にするため、各脆弱性検出ごとに個別に追跡される必要があります

計算例

シナリオ: サードパーティ依存関係における High 深刻度 (CVSSv3 8.2) の脆弱性

  • 最初の検出日: 2026 年 1 月 1 日
  • 修正が利用可能になった日: 2026 年 1 月 15 日
  • High 深刻度の SLA TTR: 30 日
  • 承認された SLA 延長: 7 日（複雑性のため）
  • 解決日: 2026 年 2 月 18 日

計算:

  • SLA 開始日: 2026 年 1 月 15 日（検出と修正可用性のうち遅い方）

  • SLA 期日: 1 月 15 日 + 30 日 + 7 日 = 2026 年 2 月 21 日

  • 解決日 (2 月 18 日) < SLA 期日 (2 月 21 日)

  • 結果:

SLA 内にクローズ ✓

最終更新 July 30, 2026: Merge pull request #483 from kyama0/translation/batch-2026-07-29-1 (c955a93f)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License