CVE修正：アドバイザリから修正済みビルドの出荷まで

CVE修正のプロセス

CVE修正とは、運用または出荷するソフトウェアから、公開された脆弱性を取り除くことです。自社のコードであればパッチを意味します。オープンソースの依存関係（一般的な製品のCVEの大半はここから生じます）であれば、脆弱性が修正されたバージョンに移行することを意味します。いずれの場合も、手順は同じです。

影響を受けるパッケージとバージョンを含むすべての製品、ビルド、リリースを特定する。
脆弱性が自社に影響するか、どの程度深刻かを評価する。
対応中の他のすべての課題と比べて優先順位を付ける。
アップグレード、パッチ適用、置き換え、または修正がない場合は緩和策によって修正する。
新しいビルドに実際に含まれているのが修正済みのバージョンであることを検証する。
何が影響を受け、何を判断し、修正がいつ出荷されたかを記録する。

ステップ1：影響を受けるすべてのビルドを特定する

アドバイザリが出て最初に問われるのは、そのパッケージがどこにあるかです。ソースリポジトリからこの問いに答えるのは時間がかかり、しばしば誤りも生じます。ロックファイル内のバージョン、ビルドが解決したバージョン、リリースしたコンテナイメージ内のバージョンは、それぞれ異なることがあるからです。推移的依存関係や、ビルドがパッケージマネージャーを介さずにダウンロードするパッケージは、マニフェストにまったく現れません。

信頼できる答えは、各リリースのSBOMをアドバイザリと継続的に照合することで得られます。そのSBOMがビルド中に記録されたものであれば、ビルドが実際に使ったものが記載されているため、照合によって、どのリポジトリが脆弱なバージョンに言及しているかではなく、出荷したどのビルドがそれを含んでいるかがわかります。

ステップ2：深刻度と悪用状況で優先順位を付ける

深刻度だけでは、あまりに多くの脆弱性が緊急と判定されます。多くのチームは3つのシグナルを組み合わせています。

シグナル	わかること	公開元
CVSS	悪用された場合の脆弱性の深刻度（0〜10のスコア）	FIRST（標準を策定）。スコアはNVDやベンダーが公開
EPSS	今後30日以内に悪用される推定確率	FIRST
KEV	脆弱性が実際に悪用されていることが知られているかどうか	CISAのKnown Exploited Vulnerabilitiesカタログ

そのうえで、自社の状況を加味します。影響を受けるパッケージが顧客に出荷されるのか、テストジョブでのみ実行されるのか、そして脆弱な関数がそもそも使われているかどうかです。出荷するパッケージに含まれる、悪用が確認された脆弱性は、リストの最上位に置きます。脆弱性の優先順位付けでは、これらのシグナルを手法として体系化しています。

修正の期限

CISA BOD 26-04。2026年6月10日以降、米国連邦政府機関は4つの問いから各期限を設定しています。資産が外部に公開されているか、脆弱性がKEVカタログに掲載されているか、悪用を自動化できるか、部分的または完全な制御を与えるか、の4点です。期限は、最悪のケースでフォレンジックによるトリアージを伴う3日から、次回のシステムアップグレード時の修正までさまざまです。これは、KEVの大半のエントリーに2週間の期限を設けていたBOD 22-01に代わるものです。
EUのCyber Resilience Act。メーカーは、セキュリティアップデートの提供を含め、脆弱性に遅滞なく対処し修正しなければなりません（附属書I、第II部）。2026年9月11日以降、製品内の脆弱性が実際に悪用されている場合には報告の期限も始まります。24時間以内の早期警告、72時間以内の通知、修正が利用可能になってから14日以内の最終報告です。
自社のポリシー。多くのセキュリティプログラムは、深刻度に応じた社内目標を設定しています。目標がどうであれ、それを達成できるのはステップ1が迅速な場合だけです。

ステップ3：修正方法を選ぶ

選択肢	使う場面
アップグレード	修正済みのバージョンが存在する場合。破壊的変更を抑えるため、修正を含む最小限のアップグレードを選びます。
親パッケージのアップグレード	脆弱なパッケージが推移的依存関係である場合。直接の依存関係の新しいリリースが、修正を取り込んでいることがよくあります。
オーバーライド	親パッケージが修正をリリースしていない場合。npmの`overrides`、Yarnの`resolutions`、`pnpm.overrides`で推移的依存関係のバージョンを強制し、テストします。
パッチまたはバックポート	修正済みのメジャーバージョンにまだ移行できない場合。上流の修正を、使用中のバージョンに適用します。
置き換え	パッケージがメンテナンスされていない、またはCVEが繰り返し発生する場合。代替のパッケージに移行します。
緩和と文書化	修正がまだ存在しない、または自社製品が影響を受けない場合。影響範囲を減らし、評価結果を記録します（たとえばVEXステートメントとして）。

このステップの大部分は、バージョンの選定からプルリクエストの作成まで自動化できます。脆弱性修正の自動化では、何を自動化し、何を人に任せるべきかを解説しています。

ステップ4：マージされた修正は、出荷された修正ではない

プルリクエストがマージされたので、CVEはクローズ。そうとは限りません。修正はリポジトリに入っていても、ビルドが古いキャッシュを復元したり、ベースイメージがまだ古いパッケージを含んでいたり、リリースブランチが変更を取り込んでいなかったりします。チケットは修正済みになっているのに、製品はまだ脆弱なバージョンを出荷しているのです。

最後は出荷側から確認して完結させます。次のビルドのSBOMを確認し、脆弱なバージョンがなくなったことを確かめます。そのSBOMが、キャッシュから復元されたパッケージを含めてビルドが実際に取得したものを記録していれば、この確認によって、顧客、監査人、規制当局が本当に知りたい問いに答えられます。

CRACIによるCVE修正の支援

特定。CRACIは、推移的依存関係やキャッシュから復元されたパッケージを含め、各GitHub Actionsジョブが取得したパッケージを記録し、監視対象のSBOMを継続的に再評価します。組織ビューではビルドとリポジトリをまたいで検出結果を集約するため、新しいCVEがどのビルドに影響するかがわかります。
割り当て。セキュリティチームは各検出結果をトリアージし、修正を担当するチームに送ります。CRACIはVEXに対応しており、脆弱性が自社製品にどう影響するかを記録できます。
検証。新しいビルドごとに完全性の状態を備えた独自のSBOMが生成されるため、ビルドが使ったのが修正済みのバージョンであることを確認できます。
報告。CRAの対象となる実際に悪用されている脆弱性については、CRACIが通知の内容を準備し、メーカーの担当者がSingle Reporting Platformを通じて提出します。

機能の全体像は脆弱性トラッキングをご覧ください。

CVE修正：よくあるご質問

CVE修正とは何ですか？

CVE修正とは、CVE IDで識別される公開済みの脆弱性を、運用または出荷するソフトウェアから取り除くことです。依存関係の場合は通常、脆弱性が修正されたバージョンへのアップグレードを意味します。自社のコードの場合は、パッチを当てることを意味します。

どのCVEから修正すべきか、どう優先順位を付ければよいですか？

深刻度と悪用のエビデンスを組み合わせます。CVSSは脆弱性の深刻さを示し、EPSSは今後30日以内に悪用される可能性を推定し、CISAのKnown Exploited Vulnerabilitiesカタログはすでに悪用されているものを掲載しています。出荷するパッケージに含まれる、悪用が確認された脆弱性が最優先です。

CVEはどのくらいの速さで修正する必要がありますか？

誰が求めるかによります。CISAの拘束力のある運用指令（BOD）26-04は、米国連邦政府機関に対し、脆弱性がKEVカタログに掲載されているか、資産が外部に公開されているか、悪用を自動化できるか、攻撃者にどの程度の制御を与えるかに応じて、3日から次回のシステムアップグレードまでの期限を定めています。EUのCyber Resilience Actはメーカーに対し脆弱性を遅滞なく修正するよう求めており、2026年9月11日以降、製品内の脆弱性が実際に悪用されている場合には24時間の報告期限が始まります。

修正済みのバージョンがまだない場合はどうすればよいですか？

緩和して文書化します。可能であれば影響を受ける機能を無効にし、攻撃経路を遮断するか、コンポーネントを入れ替え、評価結果を記録します（たとえばVEXステートメントとして）。そのうえで修正版のリリースを注視し、公開されたら修正します。

推移的依存関係のCVEはどう修正すればよいですか？

まず、それを取り込んでいる直接の依存関係のアップグレードを試します。新しいリリースが修正を取り込んでいることがよくあるからです。まだ存在しない場合、ほとんどのパッケージマネージャーでは推移的パッケージのバージョンを強制できます。npmではoverrides、Yarnではresolutions、pnpmではpnpm.overridesです。親パッケージはそのバージョンを前提にビルドされていないため、結果をテストしてください。