SLA 例外
はじめに
GitLab における SLA 例外には、わずかに異なる手続きを伴う 2 つの形式があります。手続きの違いは、脆弱性検出が見つかった資産（イメージ、サーバー、パッケージ）が FedRAMP 境界または環境内に出荷・使用されている場合にのみ適用されます。一般的に概要として、FIPS 準拠イメージ内の検出は FedRAMP の対象範囲となり、SLA 例外を申請する際もその前提で扱う必要があります。
FedRAMP の用語では、SLA 例外は Deviation Request と呼ばれます。
FedRAMP かどうかにかかわらず、SLA 例外とは一般に、脆弱性が適切な期限または SLA 内に修正できなかった理由を記述・記録するための脆弱性管理アーティファクトです。これらの期限は GitLab では SLA（Service Level Agreement）と呼ばれ、脆弱性修復 SLA ハンドブックページ に記載されています。私たちは、コンテナイメージやパッケージなど、GitLab のシステムや出荷される資産におけるすべての検出について、これらの SLA を遵守するよう取り組んでいます。脆弱性に対する SLA 例外を申請する一環として、脆弱性、その影響、悪用される可能性、修復への障壁の詳細が考慮され、新しい SLA が割り当てられる場合があります。すべての SLA 例外申請には、レビューが必要な脆弱性に関する詳細を含めなければなりません。
一般情報
リスク受容と SLA 例外
コード、コンテナイメージ、または稼働中のコンテナやサーバー上の脆弱性を修復する際、最新の依存関係、パッケージ、コンテナベースイメージを使用することが技術的に常に可能とは限りません。GitLab を製品およびサービスとして安定性とパフォーマンスを確保する必要性、または実際に修正が提供されないなど GitLab の制御外の要因により、SLA を過ぎた後でないと脆弱性を解決できない場合があります。
このような状況では、SLA 例外申請を行うことで、脆弱性に対する SLA タイマーの期間を延長したり「時計を止めたり」できます。これにより、追加のコンテキストや状況を考慮しながら脆弱性を解決するためのより多くの時間が得られます。
コード、コンテナイメージ、または稼働中のコンテナやサーバー上の脆弱性を修復する際、最新の依存関係、パッケージ、コンテナベースイメージを使用することが技術的に常に可能とは限りません。GitLab を製品およびサービスとして安定性とパフォーマンスを確保する必要性、または実際に修正が提供されないなど GitLab の制御外の要因により、SLA を過ぎた後でないと脆弱性を解決できない場合があります。
FedRAMP 対象 vs FedRAMP 対象外の検出
このハンドブックページでは「FedRAMP」検出と「FedRAMP 対象外」検出を区別して言及します。FedRAMP 検出とは、FedRAMP 境界内にデプロイされた環境、または FedRAMP 境界内にデプロイ・使用されているソフトウェアコンポーネントやアーティファクトに関連する検出です。
FedRAMP のすべての検出について、SLA 例外は Deviation Request 手続きを使って記録されます。Deviation Request または FedRAMP 関連検出の SLA 例外について言及されている箇所では、FedRAMP 固有のガイダンスや現行の報告要件についてこのドキュメントを確認してください。
FedRAMP 対象外のすべての検出について、SLA 例外は 脆弱性例外テンプレート を使った新規ワークアイテムによって記録されます。これらの SLA 例外は、脆弱性に対する FedRAMP 対象外のリスク調整・例外を一元化する重要な仕組みです。
SLA 例外を申請するのが適切でないのはどのような場合か？
GitLab の制御内の理由で SLA を満たせなかった場合は、SLA 例外を申請すべきではありません。これには、グループ間・チーム間の連携が必要な脆弱性、計画的または非計画的な不在によるチームメンバーの不在、機能開発や他のバグ修正など他の優先度の高い作業がある場合などが含まれます。
このような状況で SLA を満たせない場合、SLA/SLO の未達・違反および関連する Issue は、特定のマイルストーンに計画されたバグや機能が達成できなかった場合と同様に、通常のグループ開発レトロスペクティブの一環としてレビューされるべきです。
このような状況を防ぐための一般的なシナリオや提案は次のとおりです:
- 通常のバグトリアージローテーションの一環として脆弱性 SLA と残り時間を確認し、SLA がギリギリであったり既に違反していないかを確認する
- 脆弱性 Issue にはアサインとオーナーを設定し、計画的・非計画的な不在時にもオーナーが脆弱性を引き継ぐようにする
- 脆弱性 Issue は通常のレトロスペクティブやマイルストーン計画作業の一部として扱う
SLA 例外申請が適切なのはどのような場合か？
脆弱性に対する SLA 期間を延長したり「時計を止める」のが適切な場面はいくつかあります。
FedRAMP 検出
FedRAMP 緩和状況または緩和コントロール
インフラシステム、ソフトウェアプロジェクト、コンテナイメージにおいて、コンポーネントが脆弱性が存在しないか悪用不可能な使われ方をしているために脆弱性が検出されることがあります。このような場合の緩和コントロールは、影響が SLA の計算に使った当初の深刻度より低いか、脆弱性に影響がまったくないかを意味します。 GitLab が出荷するコード、イメージ、パッケージから脆弱なコードを取り除いて解決することは依然として重要ですが、緩和状況がある場合、このシナリオで脆弱性よりも他の作業を優先することができ、それは脆弱性の実際の影響に応じて適切です。
例: 依存関係として使用されているソフトウェアライブラリの XML インポート機能に XXE 脆弱性があるが、プロジェクトはそのライブラリの XML インポート機能を無効化しているか使用していない、というケース。
緩和状況や緩和コントロールが存在する検出について、FedRAMP のガイドライン下では SLA 例外は適切ではありません。
FedRAMP 誤検知
実際には存在しない脆弱性が、脆弱性スキャナによってソフトウェア内で見つかることがあります。これは不正確な検出方法、またはスキャナの機能制限により検出周辺のコンテキストが限られていることに起因する可能性があります。誤検知とは、そもそも脆弱性が検出されるべきでなかった状況を指し、脆弱性は存在するが他の緩和要因により悪用不可能な状況を指すものではありません。 このような場合、修復すべき脆弱性は存在せず、その脆弱性は誤検知として扱うことができます。
この検出について SLA を満たせないことに対処するために、誤検知 Deviation Request をオープンできます。
FedRAMP リスク・深刻度の調整
ベンダーによって再パッケージ化されたソフトウェア（OS パッケージなど）は、ソフトウェアがどのようにパッケージ化されているか、デフォルト設定がどうなっているかに基づいて、パッケージ内の脆弱性の深刻度評価が異なることがしばしばあります。 緩和コントロールや状況も存在する可能性があり、それが脆弱性の実際の深刻度に影響します。
このような場合、通常の SLA に対する例外が適切となることがあります。
FedRAMP 環境では、検出のリスク調整についてはるかに具体的なルールがあり、Deviation Request 手続きの Risk Adjustment セクション に詳述されています。このハンドブックページが適切であると示している場合は、Risk Adjustment DR を作成できます。
FedRAMP ベンダー依存関係と修正の可用性
ベンダー依存関係は、ソフトウェアベンダーによっては、独自の報告、分析、スコアリングのライフサイクルを持っており、それはベンダーアドバイザリで表現されます。例えば、Red Hat は Red Hat によってパッケージ化・配布されたソフトウェアの結果と修正済みバージョンを詳述する RHSA（Red Hat Security Advisories）をリリースします。このプロセスの結果として、ベンダーがパッケージ化したバージョンには脆弱なコードが含まれない、デフォルト設定では悪用できない、または悪用にはベンダーのパッケージで無効化されている機能の有効化が必要であると判断された場合などに、修正が提供されないことがしばしばあります。
修正のリリースが遅延している状況では、ラベルやアドバイザリ情報の手動調査が、修正がまだ「未提供」または「unavailable」であることを示します。この場合、SLA を延長する例外が適切です。
修正がまったくリリースされない状況では、手動調査やアドバイザリ情報、または自動付与された「will not be fixed」ラベルが示すとおり、SLA から除外する例外がこの場合に適切です。
サードパーティ（GitLab 以外）の依存関係における脆弱性については、SLA の修復期限はパッチ／修正がリリース／公開された時点でリスタートします。
FedRAMP 環境では Deviation Request をオープンすべきです。これをどのように扱うかについては、Operational Requirement DR Procedure に詳述された具体的なルールがあります。多くの場合、これらは 自動的に 作成できます。自動 DR 作成が適用されない場合は、SLA を調整するために Operational Requirement DR を手動でオープンできます。
FedRAMP 運用上・技術上の要件
運用上または技術上の要件によって SLA 内での脆弱性解決が技術的に実現不可能、または GitLab ソフトウェアやシステムの安定性や可用性に対するリスクとなる場合、他の緩和策を導入できるならば例外 SLA が適切となる場合があります。
FedRAMP のガイダンスでは、これは検出の SLA を延長したり除外する正当な理由とは見なされません。この場合、Security は開発グループと連携して、SLA を満たせる代替アプローチを見つけるべきです。
FedRAMP Deviation Request 手続き
FedRAMP 関連の脆弱性については、すべての例外申請は FedRAMP 脆弱性 Deviation Request 手続き に従わなければなりません。サードパーティ（GitLab 以外）の依存関係における脆弱性については、SLA の修復期限はパッチ／修正がリリース／公開された時点でリスタートします。
FedRAMP 対象外の検出
FedRAMP 対象外 緩和状況または緩和コントロール
インフラシステム、ソフトウェアプロジェクト、コンテナイメージにおいて、コンポーネントが脆弱性が存在しないか悪用不可能な使われ方をしているために脆弱性が検出されることがあります。このような場合の緩和コントロールは、影響が SLA の計算に使った当初の深刻度より低いか、脆弱性に影響がまったくないかを意味します。 GitLab が出荷するコード、イメージ、パッケージから脆弱なコードを取り除いて解決することは依然として重要ですが、緩和状況がある場合、このシナリオで脆弱性よりも他の作業を優先することができ、それは脆弱性の実際の影響に応じて適切です。
例: 依存関係として使用されているソフトウェアライブラリの XML インポート機能に XXE 脆弱性があるが、プロジェクトはそのライブラリの XML インポート機能を無効化しているか使用していない、というケース。
優先度の高いエンジニアリング作業のためにコンポーネントの更新を安全に遅らせることができる場合、例外 Issue が適切です。緩和状況や緩和コントロールを説明する分析が必要となり、それがレビューされて、修復を安全に遅らせることができることを確認します。更新後の SLA は更新後の深刻度評価を表すべきであり、これが新しい SLA の計算に使われます。FedRAMP 検出では、個々の深刻度に紐づく SLA は固定されており、1 段階の深刻度のみ調整できます（例えば critical は high にしか調整できず、low には調整できません）。FedRAMP 対象外の検出ではより柔軟性があります。
FedRAMP 対象外 誤検知
実際には存在しない脆弱性が、脆弱性スキャナによってソフトウェア内で見つかることがあります。これは不正確な検出方法、またはスキャナの機能制限により検出周辺のコンテキストが限られていることに起因する可能性があります。誤検知とは、そもそも脆弱性が検出されるべきでなかった状況を指し、脆弱性は存在するが他の緩和要因により悪用不可能な状況を指すものではありません。 このような場合、修復すべき脆弱性は存在せず、その脆弱性は誤検知として扱うことができます。
スキャン設定やスキャナ自体で誤検知に対処できるまで SLA を一時的に延長するために例外を作成できます。これが実現不可能な場合は、恒久的な例外も適切となる場合があります。
FedRAMP 対象外 リスク・深刻度の調整
ベンダーによって再パッケージ化されたソフトウェア（OS パッケージなど）は、ソフトウェアがどのようにパッケージ化されているか、デフォルト設定がどうなっているかに基づいて、パッケージ内の脆弱性の深刻度評価が異なることがしばしばあります。 緩和コントロールや状況も存在する可能性があり、それが脆弱性の実際の深刻度に影響します。
このような場合、通常の SLA に対する例外が適切となることがあります。
SLA を延長し、脆弱性の深刻度を調整するために例外を作成できます。
FedRAMP 対象外 ベンダー依存関係と修正の可用性
ベンダー依存関係は、ソフトウェアベンダーによっては、独自の報告、分析、スコアリングのライフサイクルを持っており、それはベンダーアドバイザリで表現されます。例えば、Red Hat は Red Hat によってパッケージ化・配布されたソフトウェアの結果と修正済みバージョンを詳述する RHSA（Red Hat Security Advisories）をリリースします。このプロセスの結果として、ベンダーがパッケージ化したバージョンには脆弱なコードが含まれない、デフォルト設定では悪用できない、または悪用にはベンダーのパッケージで無効化されている機能の有効化が必要であると判断された場合などに、修正が提供されないことがしばしばあります。
修正のリリースが遅延している状況では、ラベルやアドバイザリ情報の手動調査が、修正がまだ「未提供」または「unavailable」であることを示します。この場合、SLA を延長する例外が適切です。
修正がまったくリリースされない状況では、手動調査やアドバイザリ情報、または自動付与された「will not be fixed」ラベルが示すとおり、SLA から除外する例外がこの場合に適切です。
検出が「fix unavailable」または「will not be fixed」のいずれかであるかに応じて、一時的または恒久的な SLA 除外のために例外 Issue を作成すべきです。
FedRAMP 対象外 運用上・技術上の要件
運用上または技術上の要件によって SLA 内での脆弱性解決が技術的に実現不可能、または GitLab ソフトウェアやシステムの安定性や可用性に対するリスクとなる場合、他の緩和策を導入できるならば例外 SLA が適切となる場合があります。
FedRAMP 対象外環境では、Security と担当する開発グループが潜在的な緩和策について連携し、適切であれば検出の修復のために SLA を延長できるよう、例外 Issue を作成すべきです。
FedRAMP 対象外 リスク受容・SLA 例外手続き
FedRAMP 対象外のイメージ、プロジェクト、またはインフラシステム上で例外候補となる脆弱性を特定した場合は、exception テンプレートを使って 脆弱性例外 Issue をオープンしてください。
テンプレートで要求されている関連情報をすべて記入してください。参考までに、必要な情報は次のとおりです:
- 脆弱性の説明（CVE またはその他の識別子を含む）
- 脆弱性の優先度／深刻度
- 上記 SLA に基づく当初の修復期日
- 申請する例外の期間
- 該当する資産またはプロジェクトのリスト（ホスト、コンテナイメージ、GitLab リポジトリなど）
例外の概要的な正当性とそれが適切である理由を説明する必要があります。緩和策、補完コントロール、または脆弱性の影響軽減を裏付ける分析を説明するのに役立つと考えられる技術的な詳細を提供していただけると（歓迎です！）助かります。
これらすべては、私たちが例外がどの程度適切かを迅速に判断し、SLA 内に脆弱性を緩和できる別の方法があるかを判断するのに役立ちます。
脆弱性例外は次のカテゴリにグループ化できます:
| 例外タイプ | 例外期間 | 説明 |
|---|---|---|
| ~“risk treatment::remediate | N/A | 脆弱性は修復され、例外申請は不要です |
| ~“risk treatment::mitigate severity::remediate” | N/A | 補完コントロールが導入されているため深刻度レベルを引き下げるべきです。 |
| ~“risk treatment::mitigate severity::accept” | 恒久 | 補完コントロールが導入されているため深刻度レベルを引き下げるべきであり、かつリスクを受容すべきです（つまり修正されません）。 |
| ~“risk treatment::false positive” | 恒久 | 脆弱性は誤って報告されたものであり、実際には存在せず、いかなる方法でも悪用できません。 |
| ~“risk treatment::operational requirement” | 一時 | パッチリリースのないサードパーティ依存関係や、アップグレードに破壊的変更が必要なパッケージバージョンへの依存などにより、運用上の不安定性を引き起こさずに脆弱性を修正することができません。 |
| ~“risk treatment::accept” | 恒久 | 脆弱性は受容されるべき（多くの場合、リスクが非常に低いため）であり、修正されません。 |
リストされたラベルは私たちの SLA 遵守と GitLab に関連するリスクの報告に有用です。どれを適用すべきか不明な場合は、例外申請をオープンする際にお問い合わせください。Vulnerability Management チームが正しいものを適用します。
例外期間の制限
現在、優先度／深刻度に基づき次のような例外期間を許可しています:
| P/S | 30 日 | 60 日 | 90 日 | 365 日 |
|---|---|---|---|---|
| ~“priority::1” or ~“severity::1” | Yes | No | No | No |
| ~“priority::2” or ~“severity::2” | Yes | Yes | Yes | No |
| ~“priority::3” or ~“severity::3” | Yes | Yes | Yes | Yes |
| ~“priority::4” ~“severity::4” | Yes | Yes | Yes | Yes |
時間ベースでない例外（例: 誤検知向け）については、恒久的な例外があります。恒久的な例外が適切であると考える場合は、Issue をオープンする際にお知らせください。恒久的な例外が適切かどうかを確認します。一般的に、時間ベースの例外が望ましいです。なぜなら、たとえ誤検知であっても、検出に対処するための選択肢を一緒に検討する機会が得られるためです。
例外承認者
Issue がオープンされた後、申請者はリンクされた脆弱性が最初に検出された時点に基づいて、適切な SLA に合うように期日を割り当てる必要があります。
申請は Vulnerability Management チームのメンバーによってレビューされ、適切であれば承認されます。承認されない場合、脆弱性のリスクを緩和する方法、または SLA 内に修復する方法についてガイダンスが提供されます。
ご質問がある場合や、より緊急の懸念をご相談されたい場合は、Slack の #g_security_vulnmgmt チャネルまでお気軽にお問い合わせください。
bfd74782)