脆弱性ライフサイクル
追跡 Issue のライフサイクル
GitLab における脆弱性検出の典型的なライフサイクルは、概要レベルでは次のステップで進みます:
- スキャナによって脆弱性が検出される、またはその他の方法で報告される
- 脆弱性を追跡するための GitLab Issue が作成される
- 脆弱性が SLA 内で修復される
- Issue がクローズされる
環境やスキャン対象によって、追跡 Issue は異なる GitLab チームメンバーによって取り扱われます。 Issue は、検出と修復のプロセスを効率化する VulnMapper などのさまざまな自動化ツールによってさらに充実されることもあります。 SLA 内で Issue を修復できない場合は、脆弱性の SLA を調整したり SLA から除外したりする追加手続きが用意されています。詳細については本ページの「リスク受容と SLA 例外」セクションをご覧ください。
追跡 Issue のクローズ
開発グループによって追跡されるアクション不要な Issue の数を減らすために、修正可用性の変化や緩和要因への対応能力を損なうことなく Issue を安全にクローズできるさまざまな状況を整理しました。
脆弱性追跡 Issue は、以下の場合にクローズできます:
- 脆弱な依存関係またはパッケージが更新され、更新されたソフトウェアアーティファクト(コンテナイメージ、パッケージ)が出荷された場合
- FedRAMP 対象外のコンテナイメージにおけるベンダー依存関係について、影響がないとしてソフトウェアベンダー(例: Debian)が修正しない場合
- FedRAMP 対象のコンテナイメージにおけるベンダー依存関係について、影響がないとしてソフトウェアベンダー(例: Red Hat)が修正せず、DR がオープンされ追跡 Issue にリンクされている場合
- FedRAMP 対象外のコンテナイメージまたはプロジェクトに誤検知があり、例外 Issue が作成または更新され追跡 Issue にリンクされている場合
- FedRAMP 対象のコンテナイメージに誤検知があり、DR がオープンまたは更新され追跡 Issue にリンクされている場合
脆弱性ライフサイクルの例
GitLab 管理のインフラシステム上で Wiz.io により影響度の高い脆弱なパッケージが検出された場合
- VulnMapper によって脆弱性と追跡 Issue のペアが作成される
- GitLab の本番パッチサイクルの一環として Issue が修復される
- Issue がクローズされる
FedRAMP 対象外の GitLab コンテナイメージで影響度の高い脆弱なパッケージが検出された場合
- GitLab でコンテナスキャン検出が作成される
- 検出の修復を追跡するための Issue が作成される
- 脆弱なパッケージが更新される
- 更新されたイメージが出荷される
- Issue がクローズされる
FedRAMP 対象外の GitLab イメージで脆弱なパッケージが検出され、修正がない場合
- GitLab でコンテナスキャン検出が作成される
- 検出の修復を追跡するための Issue が作成される
- 自動 Issue ラベルや手動調査が示すとおり、ベンダーから修正は提供されない
- コンテナスキャンレポートからリンクされた脆弱性検出は却下される
- Issue がクローズされる
FedRAMP 対象外の GitLab イメージで影響度の高い脆弱性が検出され、修正がある場合
- GitLab でコンテナスキャン検出が作成される
- 検出の修復を追跡するための Issue が作成される
- 自動 Issue ラベルや手動調査が示すとおり、ベンダーから修正は提供されない
- コンテナスキャンレポートからリンクされた脆弱性検出は却下される
- Issue がクローズされる
GitLab ソフトウェアプロジェクトで使用されている依存関係に影響度の高い脆弱性が見つかった場合
- GitLab で依存関係スキャン検出が作成される
- 検出の修復を追跡するための Issue が作成される
- 依存関係が更新される
- 更新されたバージョンのソフトウェアが出荷される
- Issue がクローズされる
GitLab プロジェクトで使用されている依存関係に影響度の高い未修正の脆弱性が見つかった場合
- GitLab で依存関係スキャン検出が作成される
- 検出の修復を追跡するための Issue が作成される
- 担当する開発グループが、ライブラリのメンテナまたはその依存関係の GitLab オーナーと連携して修正可用性を把握する
- メンテナが SLA 内で修正は提供されないことを示す
- 脆弱性の影響を検証または緩和するために、緩和コントロールが検討される
- 緩和コントロールや代替ライブラリへの切り替えを SLA 内に実装できない
- SLA を必要に応じて延長するために検討した選択肢を詳述する例外 Issue がオープンされる
- 修正または緩和を組み込んだ更新版のソフトウェアが出荷される
- Issue がクローズされる
GitLab プロジェクトで使用されている依存関係に修正されない脆弱性が見つかった場合
- GitLab でスキャン検出が作成される
- 検出の修復を追跡するための Issue が作成される
- 担当する開発グループが、ライブラリのメンテナまたはその依存関係の GitLab オーナーと連携して修正可用性を把握する
- 応答がない、プロジェクトがメンテナンスされていない、または何らかの理由で脆弱性が却下され修正されない、のいずれかである
- 脆弱性の影響を検証または緩和するために、緩和コントロールが検討される
- 緩和コントロールや代替ライブラリへの切り替えを SLA 内に実装できない
- SLA を必要に応じて延長するために検討した選択肢を詳述する例外 Issue がオープンされる
- 修正または緩和を組み込んだ更新版のソフトウェアが出荷される
- Issue がクローズされる
影響度の高い脆弱なパッケージが検出された場合
GitLab FedRAMP コンテナイメージにおいて
- GitLab でコンテナスキャン検出が作成される
- 検出の修復を追跡するための Issue が作成される
- Red Hat が公開する修正可用性データに基づき、VulnMapper によって、適切な 脆弱性管理ラベル が Issue に自動付与される
- ラベルが示すとおり修正が利用可能であり、担当する開発グループが修正済みパッケージでイメージを更新する
- 更新されたイメージが FedRAMP 環境に出荷された時点で Issue がクローズされる
ベンダーが修正しないと判断した脆弱なパッケージが検出された場合
GitLab FedRAMP コンテナイメージにおいて
- GitLab でコンテナスキャン検出が作成される
- 検出の修復を追跡するための Issue が作成される
- Red Hat が公開する修正可用性データに基づき、VulnMapper によって、適切な 脆弱性管理ラベル が Issue に自動付与される
- ラベルや手動調査が示すとおりベンダーから修正が提供されない場合、Deviation Request のドキュメントを確認し、修復のための SLA を調整するために Deviation Request が適切かどうかを検討する
- VulnMapper の自動化、または担当する開発グループによって DR が作成される
- Issue が DR Issue にリンクされた時点で、脆弱性追跡 Issue をクローズしてもよい
ベンダーがまだ修正していない脆弱なパッケージが検出された場合
GitLab FedRAMP コンテナイメージにおいて
- GitLab でコンテナスキャン検出が作成される
- 検出の修復を追跡するための Issue が作成される
- Red Hat が公開する修正可用性データに基づき、VulnMapper によって、適切な 脆弱性管理ラベル が Issue に自動付与される
- SLA の期日までにベンダーから修正が提供されない可能性が高い場合(ラベルが未修正であることを示す場合)、Deviation Request のドキュメントを確認し、修復のための SLA を調整するために Deviation Request が適切かどうかを検討する
- VulnMapper の自動化、または修復を担当するグループによって DR が作成される
- Issue はオープンのままであり、修正が利用可能になると VulnMapper またはチームメンバーによってラベルが更新される
- 脆弱なパッケージが修正済みバージョンに更新され、新しいイメージが出荷される
- Issue が修復・デプロイされた時点で追跡 Issue をクローズできる
最終更新 June 14, 2026: Merge pull request #403 from kyama0/claude/cool-turing-ls6eck (
bfd74782)