脆弱性管理の定義: 修正済みとは何を意味するか？
概要
GitLab では、脆弱性検出が見つかると、それは 1 つ以上の資産（サーバー、コンテナイメージ、パッケージなど）に対して検出されます。 脆弱性検出を修復する、つまり「修正する」際は、脆弱性検出を修正済みとみなす前に、検出された finding の完全な修復を行い、もはや検出されないか悪用できないことを検証することが重要です。
このハンドブックページには、さまざまな種類の検出に対する複数のシナリオが含まれており、「完了の定義」と修正済み脆弱性とは何かを示しています。
コード内の脆弱性検出
GitLab のコード内で脆弱なコードが検出または報告された場合、脆弱性検出を修正済みとみなすには、脆弱性に対処し、もはや存在しないことを検証し、GitLab ユーザーおよび GitLab を self-host するユーザーに対してパッケージ化された形でコードのバージョンを利用可能にする必要があります。これには、GitLab のホステッド環境または管理環境のインストールへのデプロイを担当する GitLab チームメンバーに修正を利用可能にすることも含まれます。修正を含むバージョンが出荷されてユーザーがアクセスできるようになるまで、脆弱性は修正済みとみなされません。コード内の脆弱性は、デプロイされる前であっても、更新済みのパッケージまたはイメージが意図された消費者に利用可能になっていれば、修正済みとみなされます。GitLab が責任を負う管理またはホステッド環境の場合、修復済みコードのデプロイ（パッケージまたはイメージを介して）がホステッド環境または管理環境に対して実行されてから、それらの環境において脆弱性が修正済みとみなされます。これが SLA の観点でどのように機能するかについての詳細は、SLA ハンドブックページをご覧ください。
GitLab パッケージまたはコンテナイメージ内の脆弱性検出
コード内の脆弱性検出と同様に、私たちがイメージやパッケージ内に同梱するサードパーティ依存関係に脆弱性がある場合、修正済みバージョンのパッケージまたはイメージが意図された消費者によってインストール可能になるまで修正済みとはみなされません。パッケージまたはイメージ内の脆弱性は、ユーザーによってデプロイまたはインストールされる前であっても、依然として修正済みとみなされます。GitLab が責任を負う管理またはホステッド環境の場合、修復済みパッケージとイメージのデプロイがホステッド環境または管理環境に対して実行されてから、それらの環境において脆弱性が修正済みとみなされます。これが SLA の観点でどのように機能するかについての詳細は、SLA ハンドブックページをご覧ください。
GitLab 管理インフラ内の脆弱性検出
Kubernetes やクラウドサーバーを中心に構築された管理環境などのホステッドインフラ内の検出については、特定の advisory について、その環境を構成するホステッド Kubernetes ワークロードまたはクラウドサーバーのいずれにも脆弱性のさらなる検出がない場合に、特定の環境について脆弱性 finding が修復済みとみなされます。コンテナやサーバーなどの個々のワークロードレベルでは、コンテナまたはサーバーが再スキャンされ再検証されたときに脆弱性がもはや finding として検出されない場合に、脆弱性は修正済みとみなされます。GitLab 管理環境にデプロイされた GitLab コード内の finding の検出については、SLA の観点から、コード、パッケージ、またはイメージ内の脆弱性の検出と、そのコード、パッケージ、またはイメージを実行しているホステッドワークロード上の脆弱性の検出を別個のものとして扱います。これがどのように機能するかについての詳細は、SLA ハンドブックページをご覧ください。
bfd74782)