脆弱性管理ライフサイクル：ソフトウェア製品チームのための解説

脆弱性管理ライフサイクルとは？

脆弱性管理ライフサイクルとは、製品ベンダーが出荷するソフトウェアの脆弱性に対処するために繰り返し実施するプロセスです。脆弱性を受け付けるか発見し、検証し、影響範囲を特定し、修正し、修正をリリースし、顧客に通知します。ベンダー組織では通常、製品セキュリティインシデント対応チーム（PSIRT）がこのプロセスを運営し、エンジニアリングチームが修正を担当します。

このページではベンダー側を扱います。組織が運用するサーバーやノートPCをスキャンしてパッチを当てるIT脆弱性管理は、用語こそ共通ですが、難しい部分は共通していません。ベンダーは、顧客の手元にあるサポート対象のすべてのリリースに責任を負い、発見した内容を公表しなければなりません。

ライフサイクルの各段階

受付または発見。脆弱性は、開示プログラムを通じた外部研究者、顧客、各国のCSIRTなどの調整機関、そして自社の監視から届きます。自社の監視とは、オープンソースの依存関係における新しいCVE、スキャナーの検出結果、社内テストなどです。それぞれに追跡IDを付けて記録し、外部の報告者には受領を伝えます。
検証とトリアージ。問題を再現するか依存関係の一致を確認し、自社製品の脆弱性かどうかを判断して、重大度と緊急度を評価します。該当しないものは、後で示せる理由を添えてクローズします。EPSSやCISA KEVカタログなどの優先順位付けの指標が、残ったものの順位付けに役立ちます。
影響を受ける製品とバージョンの評価。脆弱なコードやコンポーネントを含むすべての製品、リリース、サポート対象ブランチと、それを使っているすべての顧客環境を特定します。この段階で、修正とアドバイザリの範囲が決まります。
修正。担当チームが修正を開発してテストします。依存関係のアップグレード、コード変更、または修正がまだできない場合は設定変更などの緩和策です。
修正のリリース。影響を受けるサポート対象ブランチごとに、顧客が信頼できるチャネルを通じて更新版を出荷します。
アドバイザリと開示。影響を受けるもの、重大度、取るべき対応を記したアドバイザリを公開し、CVE IDを採番または参照して、報告者をクレジットします。CSAFやVEXなどの機械可読形式を使えば、顧客はアドバイザリを自動で処理できます。
監視と学習。悪用や新しい情報を監視し、アドバイザリを更新し、根本原因を開発にフィードバックして、同じ種類の欠陥が再び出荷されないようにします。

ISO/IEC 30111とISO/IEC 29147

ベンダー向けにこのライフサイクルを定めた国際規格が2つあります。両者は組織の境界で役割を分けています。

	ISO/IEC 30111:2019	ISO/IEC 29147:2018
名称	脆弱性取扱いプロセス	脆弱性開示
対象範囲	組織内部で行うこと：検証、調査、優先順位付け、修正	外部とのインターフェース：報告の受付とアドバイザリの公開
主な内容	方針と組織、PSIRTの責任、取扱いの各フェーズ、サプライチェーンに関する考慮事項	関係者の役割、報告の取扱い、アドバイザリの内容、調整、開示方針
対象読者	報告された脆弱性を取り扱うベンダー	報告を受け付け、脆弱性を開示するベンダー

2つの規格は併用を前提に設計されています。ISO/IEC 30111は、準備、受付、検証、修正の開発、リリース、リリース後という6つの取扱いフェーズを定めています。また、プロセスの監視、脆弱性情報の機密保持、そしてサプライチェーンへの配慮も求めています。多くの脆弱性は、自社で書いていないコンポーネントに潜んでいるためです。どちらの規格も現行版で、直近のISOレビューで確認されており、改訂予定とされています。

他のフレームワークも同じ構成に従っています。FIRST PSIRT Services Frameworkは、作業を脆弱性の発見、トリアージと分析、修正、開示に分類しています。IEC 62443-4-1は、産業用製品のセキュア開発ライフサイクルに、セキュリティアップデートと欠陥管理を含めています。

役割

PSIRTまたは製品セキュリティチーム：プロセスを所有し、報告を受け付け、トリアージを行い、修正を調整して、アドバイザリを公開します。PSIRTチーム向けのCRACIと、PSIRTとCSIRTの違いをご覧ください。
製品・エンジニアリングチーム：コードを所有し、修正を開発・テストして、リリースを出荷します。
リリース管理：どのサポート対象ブランチにいつ修正を提供するかを決めます。
カスタマーサポートと広報：顧客からの問い合わせと、アドバイザリの読み手への対応を担います。
法務：開示、契約、規制上の通知について助言します。
外部の関係者：報告者、CERT/CCや各国のCSIRTなどの調整機関、影響を受けるコンポーネントのアップストリームのメンテナー、そして修正を適用しなければならない顧客です。

期限とSLA

必須とされる単一の期限はありません。多くのベンダーは重大度ごとに社内目標を設定し、外部向けの目標を開示方針で公表しています。典型的な構成は次のとおりです。

外部からの報告には、数営業日以内に受領を通知します。
報告者と担当チームが状況を把握できるよう、数日以内にトリアージします。
重大度と悪用状況に応じた期限で修正します。クリティカルな検出結果や悪用が確認されているものは最短の期限です。
修正が利用可能になった時点で、または修正が遅れた場合は合意した期限に開示します。

外部からの圧力が上限を決めます。研究者はしばしば開示期限を設けており（Google Project Zeroはベンダーに90日を与えます）、規制も独自の期限を加えつつあります。EUのCyber Resilience Actは、メーカーに脆弱性を「遅滞なく」修正することを求め、積極的に悪用されている脆弱性について報告期限を定めています（CRAの要件を参照）。ゼロデイのように脆弱性がすでに悪用されている場合は、すべての段階が最短の期限で進みます。

ライフサイクルが滞るところ

遅延の大半は、修正を書く作業ではありません。何を出荷したかを把握していないことから生じます。

どのリリースにコンポーネントが含まれているかわからない。あるライブラリに新しいCVEが公開されます。昨年のリリースのうちどれにそれが含まれ、どの顧客がそれを使っているのか。リリースごとの記録がなければ、チームは古いタグを再ビルドしたり、リポジトリを手作業で検索したりすることになり、アドバイザリの影響バージョン一覧は推測になります。
推移的依存関係。脆弱なパッケージの多くは、自社で選んだものではありません。何階層も下の推移的依存関係として入り込むため、マニフェストを検索しても見つかりません。
開発用依存関係によるノイズ。ロックファイルを読み取るスキャナーは、出荷されることのないテストフレームワークやビルドツールも報告します。そのたびにトリアージの時間が奪われ、重要な検出結果が埋もれてしまいます。
パッケージマネージャー外のコンポーネント。ビルドスクリプトがダウンロードするバイナリ、ベースイメージ、ベンダーのコンポーネントは、ロックファイルにまったく現れません。
担当が不明確。どのチームも担当していない検出結果は放置されます。トリアージは、修正の担当者が決まって初めて完了します。
修正が定着しない。脆弱なバージョンが別の依存関係や古いブランチを通じて戻ってきます。次のビルドに入るのを止める仕組みがないためです。

小規模チームは、こうした滞りに真っ先に直面します。どれもCVEごとに繰り返されるからです。脆弱性管理の自動化では何をどの順で自動化するかを、脆弱性ノイズを減らす方法では、重要な検出結果を埋もれさせる開発用の依存関係、重複、担当者のいない検出結果への対処を解説しています。

指標

指標	わかること
受領通知までの時間	方針どおりに報告者へ返信できているか
トリアージまでの時間	検出結果が重要かどうか誰かが判断するまで、どれだけ待たされるか
重大度別の修正までの時間	受付から修正済みリリースの提供までで測った、修正の出荷速度
アドバイザリまでの時間	修正後、顧客が情報を得るまでどれだけ待つか
目標達成率	社内SLAが守られているか（特にクリティカルな検出結果と悪用されている検出結果）
経過期間別のバックログ	滞留している検出結果とその場所
影響なし率	該当しない検出結果にどれだけのトリアージ工数が費やされているか

各段階を個別に測定してください。修正までの時間が長い原因は、影響を受けるリリースの特定に時間がかかっていることだと判明する場合がよくあります。

出荷したものの記録に基づいてライフサイクルを運用する

トリアージ以降のすべての段階は、各リリースに何が含まれているかを把握していることが前提です。CRACIはGitHub Actionsのビルドを自社のランナーで実行し、各ジョブが実際に取得したパッケージを記録します。推移的依存関係、CIキャッシュから復元されたパッケージ、どのロックファイルにも記載されていない依存関係も含まれます。各SBOMには完全性の状態が付き、 CycloneDXまたはSPDXでエクスポートできます。

CRACIは監視対象のSBOMを継続的に再評価し、ビルドとリポジトリをまたいで集約します。ベンダーのSBOMも追加できるため、購入したコンポーネントも自社のものと並べて監視されます。新しいCVEが公開されると、ビルド履歴から、脆弱な依存関係を直接または推移的に含んでいた過去のビルドがわかるため、影響を受けていた期間を把握できます。またインベントリビューでは、どのソフトウェアバージョンがどの製品にデプロイされているかがわかります。セキュリティチームはCRACIで検出結果をトリアージし、修正を担当するチームに送ります。CRACIはVEXに対応し、ポリシーゲートで特定のCVEを含むビルドをブロックできるため、修正済みの脆弱性が再び入り込むのを防げます。脆弱性トラッキングをご覧ください。

脆弱性管理ライフサイクル：よくあるご質問

脆弱性管理ライフサイクルにはどのような段階がありますか？

製品ベンダーの場合、脆弱性の受付または発見、検証とトリアージ、影響を受ける製品とバージョンの特定、修正の開発、修正のリリース、アドバイザリの公開、そして監視と学習です。ISO/IEC 30111では、フェーズを準備、受付、検証、修正の開発、リリース、リリース後と定めています。

ISO/IEC 30111とは何ですか？

ISO/IEC 30111:2019は、脆弱性取扱いプロセスに関する国際規格です。ベンダーが自社の製品やサービスで報告された脆弱性を処理し修正するための要求事項と推奨事項を、方針やPSIRTの役割から、取扱いの各フェーズ、サプライチェーンに関する考慮事項まで定めています。

ISO/IEC 30111とISO/IEC 29147の違いは何ですか？

ISO/IEC 29147は外部向けの部分、つまり報告の受付とアドバイザリの公開を扱います。ISO/IEC 30111はその間の内部での取扱い、つまり検証、調査、優先順位付け、修正を扱います。2つは併用を前提としています。29147側については協調的な脆弱性開示をご覧ください。

脆弱性トリアージとは何ですか？

トリアージとは、報告または発見された脆弱性が実在することをセキュリティチームが確認し、自社製品にとっての重大度と緊急度を判断して、修正を担当するチームに送る段階です。適切なトリアージでは、該当しない検出結果も理由を記録したうえでクローズします。

製品の脆弱性管理とIT脆弱性管理はどう違いますか？

IT脆弱性管理は、組織が運用するシステムにパッチを当てます。製品の脆弱性管理は、組織がビルドして他者に出荷するソフトウェアの欠陥を扱うため、ITチームにはない段階が加わります。リリース済みのどのバージョンが影響を受けるかを特定し、顧客に修正を出荷し、アドバイザリで顧客に知らせることです。

脆弱性取扱いプロセスではどの指標を追跡すべきですか？

報告の受領通知までの時間、トリアージまでの時間、修正までの時間、アドバイザリまでの時間をそれぞれ重大度別に追跡し、加えて社内目標を満たした検出結果の割合、経過期間別の未対応バックログ、影響なしとしてクローズした検出結果の数を追跡します。

ソフトウェアベンダーの脆弱性管理ライフサイクル