小規模チームで増え続けるCVEに対処する方法

何が変わったのか：CVEの件数

以下の数値はCVEプログラム自身のレコードに基づき、当社の CVE公開件数のトレンドページで毎日更新しています。2026/11/12 UTC時点のスナップショットでは次のとおりです。

• 2025年には47,801件のレコードが公開され、前年より20%増えました。
• 2026年はこれまでに95,494件のレコードが公開されています。1日あたり303件で、2025年の1日あたりの件数を+131%上回るペースです。
• HighまたはCriticalと評価されたものは1日あたり155件です。
• 2020年以降の全レコードのうち17%には、採番機関からもCISAのエンリッチメントからもCVSSスコアが付いていません。カバー率は改善しており、2026年の割合は6%です。
• これらのレコードを採番したのは505の組織で、上位20組織がその75%を占めています。

• HighまたはCritical
• その他の深刻度とスコアなし

1. 39 2020
2. 54 2021
3. 68 2022
4. 78 2023
5. 109 2024
6. 131 2025
7. 303 2026*

各年に公開されたレコードの1日あたりの平均です。*は当年の年初来の値を示します。出典：CVEプログラムのcvelistV5レコード、2026/11/12 UTC時点のスナップショット。月、深刻度、採番機関による絞り込みはCVE公開件数のトレンドをご覧ください。

これは一時的な悪化ではありません。件数は2020年以降毎年増えており、いくつかの構造的な変化が増加を後押ししています。

• 採番機関が増え、より広く採番するようになった。Linuxカーネルプロジェクトは2024年2月にCVE Numbering Authorityになりました。修正が入った時点では悪用可能かどうかが明らかでないことが多いため、脆弱性の可能性があるバグ修正には、安定版カーネルに取り込まれた時点でCVEを割り当てる方針を文書化しています。カーネルのCNAだけで、それ以降18,221件のレコードを公開しています。
• AIを活用した脆弱性の発見。2024年11月、GoogleのProject ZeroとDeepMindは、Big SleepエージェントがSQLiteで悪用可能なメモリ安全性のバグをリリース前に発見したと報告しました。広く使われているソフトウェアでAIエージェントがこれを成し遂げた初の公開事例だと両者は考えています。こうしたツールにより、1人の研究者が発見できる件数が増えています。
• NVDはもはやすべてをエンリッチできない。NISTによると、National Vulnerability Databaseでは2024年初めからエンリッチメントされていないCVEが滞留し、登録件数が増え続けるなかで解消できませんでした。2026年4月にはリスクベースのモデルに移行し、CISAのKnown Exploited Vulnerabilitiesカタログに載ったCVEと、連邦政府や重要ソフトウェアのCVEを優先してエンリッチし、それ以外は「すぐにはエンリッチの予定なし」として掲載しています。1つのデータベースの影響製品データに頼るプロセスは、待たされるか、見落とすことになります。
• 対応に使える時間が短くなった。Mandiantは、2018年と2019年の平均悪用所要時間を63日と測定しました。同社のM-Trends 2026レポートは、2025年をマイナス7日と推定しています。今では、パッチのリリース前に悪用が始まるのが当たり前になっています。
• 規制上の期限。EUのCyber Resilience Actのもとで、製造者は積極的に悪用されている脆弱性について、24時間以内に早期警告、72時間以内に通知、修正が利用可能になってから14日以内に最終報告を行います（CRAの要件）。この期限は、3人のチームにも300人のチームにも同じように適用されます。

これは、ソフトウェアの安全性が下がっているという意味ではありません。チームが確認すべきものの数は毎年増える一方で、チームの人数は増えないということです。

小規模チームのプロセスで何が破綻するか

件数の増加が脆弱性管理を破綻させるのは、修正すべき脆弱性が増えるからではありません。手作業の手順がCVEごとに繰り返されるからです。

手作業の手順	現在の件数で破綻する理由
インベントリを手作業で作る	スプレッドシートや監査前に作ったSBOMは、次のリリースの翌日には古くなります。
フィードを読む	HighまたはCriticalのレコードが1日155件では、誰も追いつけません。
エンジニアリングに「Xを使っているか」と尋ねる	CVEのたびに、同じ忙しい人たちに同じ質問をします。この質問自体がボトルネックです。
CVEとリポジトリごとに1件のチケット	共有ライブラリのCVEが何十件もの重複チケットになり、バックログを埋め尽くします。
顧客1社ずつに回答する	問い合わせは脆弱性の数ではなく、顧客数に比例して増えます。
PDFやWikiのドキュメント	顧客のツールはPDFを自社のインベントリと照合できないため、読み手のたびに同じ質問が来ます。
動かせない期限	悪用までの時間は短くなる一方、手作業のプロセスは件数が増えるほど遅くなります。

インベントリ。コンポーネントの一覧を手作業で管理しているチームの多くは、監査や顧客のアンケートの前に更新します。その間の一覧は、もう出荷されていないソフトウェアを表しています。そのため、CVEに関する質問はいつも、リリースに何が含まれていたかを再構築するところから始まります。

フィード。アドバイザリを読むことは、チームが最初に始める手順であり、最初に破綻する手順です。今も手作業で続けているチームの声を聞きます。脆弱性スキャンとは人がCVEフォーラムを読むことだ、というチームもあります。これはうまくいかなくなる日まではうまくいきますが、その日を知らせるシグナルはありません。

エンジニアリングへの質問。「このライブラリを使っているか、どのバージョンか」という質問は、該当しうるCVEのたびに開発者の作業を中断させます。ある2人体制のプロダクトセキュリティチームは、ついていくためだけのボタン押しが仕事になっていて、プロセスを改善する時間が残っていないと話してくれました。

チケット。共有ライブラリにCVEが見つかり、リポジトリごとにチケットが作られると、バックログは同じ判断を何度も数えることになります。チームはバックログを無視するようになり、本当に重要なチケットを見逃します。

顧客への回答。広く報じられた脆弱性やサプライチェーン攻撃の後、顧客は「影響を受けているか」と尋ねてきます。1社ずつ回答していると、時間が最も足りない日に最も多くの時間を費やすことになります。

ドキュメント。PDFの声明やWikiページは、顧客側の誰かが読まなければなりません。顧客のスキャナー、そして規制当局も次第に、機械で照合できる形式のSBOM、VEX、アドバイザリを求めるようになっています。

期限。24時間以内の早期警告や、パッチより先に現れるエクスプロイトは、キューが片付くのを待ってはくれません。

何をどの順で自動化するか

各ステップが次のステップの作業を減らすため、ツールの選択よりも順番のほうが重要です。

1. 出荷するものを把握する。 ビルドごとのSBOMで、「影響を受けているか」が検索1回で答えられる問いになります。
2. 複数の情報源と継続的に照合する。 新しいCVEを保存済みのすべてのSBOMと照合するので、誰もフィードを読む必要がありません。
3. ノイズを削減する。 出荷しないものに対する検出結果や重複は、人の目に届く前に除かれます。
4. 半自動でトリアージする。 事実は自動で埋まり、判断は人が下します。
5. すべてを機械可読にする。 各判断は一度だけ行い、すべての読み手が再利用します。
6. 一度だけ、公開で回答する。 来なかった問い合わせのコストはゼロです。

1. すべてのビルドでSBOMを自動生成する

置き換えるもの：スプレッドシートと、エンジニアリングへの質問。ビルド時に生成したSBOMはビルドが実際に使ったものを表し、出荷したバージョンごとに保存しておけば、mainだけでなく昨年のリリースについても答えられます。顧客は古いバージョンを使っているので、インベントリもそれをカバーする必要があります。

最小構成：すべてのリリースビルドでCIがSBOMを生成し、リリース成果物と一緒に保存する。さらに良い構成：ロックファイルから後で推測するのではなく、ビルドそのものから記録したSBOM。パッケージマネージャーの外で取得されたコンポーネントも含まれます（ビルド時SBOM、SBOMの自動化）。

コスト：最小構成ならパイプライン作業に1〜2日、その後はリリースごとの作業はありません。 うまくいっているサイン：どのリリースについても、誰にも尋ねずにコンポーネントを一覧できること。

2. 複数の脆弱性情報源と継続的に照合する

置き換えるもの：フィードを読む作業。照合は機械の仕事です。直前に実行したビルドのSBOMだけでなく、新しいCVEを保存済みのすべてのSBOMと照合します。出荷時には問題のなかった古いリリースも、そのコンポーネントのCVEが公開された日から影響を受けます。

情報源は1つでは足りません。NVDのエンリッチメントの滞留により、影響製品のデータは遅れて届くか、まったく届かないことがあります。GitHub Advisory DatabaseやOSVなどのエコシステムのアドバイザリは多くの場合より早く、影響を受けるパッケージのバージョンをそのエコシステム自身の言葉で示します。ENISAのEU Vulnerability DatabaseはEUの文脈を加えます。

最小構成：保存済みのすべてのSBOMを集約された情報源と毎日再スキャンし、新たな一致を報告する定期ジョブ。うまくいっているサイン：顧客に言われる前に、リリースが影響を受けていると気づけること。CRACIでの実際の姿は脆弱性トラッキングをご覧ください。

3. 誰かが見る前にノイズを削減する

置き換えるもの：重要でない検出結果の手作業によるレビュー。ノイズの大半は上流で生まれます。出荷しないものを載せたインベントリ、同じCVEを報告する複数のツール、誰も必要としない依存関係です。インベントリを正し、各検出結果をパッケージURL（PURL）、バージョン、CVEで一度だけ数え、出荷する依存関係を減らし、そのうえでCISA KEV、EPSS、VEXから悪用可能性のコンテキストを加えます。脆弱性ノイズを減らす方法で、これらの手段を1つずつ解説しています。うまくいっているサイン：出荷リリースあたりの検出結果が減り、その理由が記録に残っていること。

4. 半自動でトリアージする

置き換えるもの：検出結果ごとに人が事実を集める作業。作業を明確に分けます。

• 自動：深刻度、悪用が確認されているか、そのコンポーネントを含む製品とバージョン、担当チーム、優先度の提案、期限。
• 人：判断。修正する、緩和する、有効期限付きで受容する、または理由を付けて「影響なし」とする。

自動化してはいけないこと：理由を記録せずに検出結果を「影響なし」として閉じること。それは抑制であり、監査やインシデントで必ず問題になります。順位付けのルールは脆弱性の優先順位付けで解説しています。

最小構成：すでに並べ替えられ、情報が埋まったキューを1日15分確認する。うまくいっているサイン：すべての判断に理由が記録され、誰かが調べものをするのを待っている項目がないこと。

5. すべてを機械可読にする

置き換えるもの：人が読まなければならないPDF、Wikiページ、メール。SBOMはCycloneDXまたはSPDX（CycloneDXとSPDXの比較）、「影響なし」の判断はVEX、アドバイザリはCSAFで公開します。そうすれば顧客のスキャナーや規制当局が人を介さずに取り込めるため、各判断は一度だけ行い、尋ねてくるすべての相手が再利用できます。

小規模チームの最小構成：SBOMとVEXを、決まった場所から求めに応じて提供する。CSAFは顧客から求められ始めた段階で対応する。うまくいっているサイン：すでに回答済みの事項を、顧客のツールが指摘しなくなること。

6. 一度だけ、公開で回答する

置き換えるもの：顧客ごとのメールのやり取り。重要なCVEごとに、影響を受けるバージョンと修正済みのバージョンを示したアドバイザリやステータスページを公開し、そこへリンクする返信テンプレートを用意しておきます。答えの導き方は、ガイド「このCVEの影響を受けているか」への答え方で解説しています。返信そのもののテンプレートはサプライチェーン攻撃後に顧客へどう回答するかにあります。最も安い問い合わせは、来ない問い合わせです。うまくいっているサイン：ほとんどの問い合わせにリンク1つで回答できること。

そして修正する

依存関係を自動更新するプルリクエストで日常的な作業を進めます。レビューが回るよう、週ごとやリリースごとにまとめましょう。上流のパッケージを1つアップグレードすると、脆弱な推移的依存関係がまとめて解消されることが多く、1つずつパッチを当てるより安上がりです（脆弱性修正の自動化）。そのうえで、ビルドをブロックするポリシーゲートで、既知の問題のあるコンポーネントが再び入り込むのを防ぎます。

チーム規模別のプラン

時間は計画用の説明的な見積もりであり、ベンチマークではありません。

	1人（兼任）	2〜5人のセキュリティまたはPSIRT機能	より大きなチーム
最初に自動化するもの	ステップ1と2：ビルドごとのSBOMと継続的な照合	ステップ1〜3、次にステップ4の担当者への振り分け	6つすべて。すべてのパイプラインにポリシーゲートを導入
手作業で残るもの	HighまたはCriticalの各検出結果に対する判断、テンプレートを使った顧客への返信	判断、VEXの根拠、重要なCVEのアドバイザリ	判断、例外、そしてプロセスそのもの
週あたりの時間（説明用）	2〜4時間	1人あたり4〜8時間	フィードではなく判断の件数で決まる

すでにPSIRTを運用している場合も、同じ順番が当てはまります。プロセス全体のモデルは脆弱性管理ライフサイクルをご覧ください。CVEのたびに増える顧客からの問い合わせへの対応は、PSIRTをスケールさせる方法で解説しています。

うまくいっているかを知る方法

• CVEの公開から「影響あり」または「影響なし」の判定までの時間（製品ごと）。
• 公開済みの資料で回答できた顧客の問い合わせの割合。
• スキャンごとではなく、出荷リリースごとの検出結果数。
• 理由が記録された判断の割合。
• 脆弱性対応に費やす週あたりの時間と、それが減っているかどうか。

まず自社のベースラインを測りましょう。これらの指標には信頼できる業界ベンチマークがなく、当社も引用しません。

採用か、購入か、プロセスの変更か

• 採用するのは、自社コードの脆弱性を修正する作業や、判断が求められる顧客向けのセキュリティ業務が中心の場合です。
• ツールを購入するのは、CVEごとに繰り返される手順、つまりステップ1、2、3、5です。
• プロセスを変えるのは、担当と期限、つまり誰がいつまでに判断するかです。

最後の点には正直に向き合いましょう。担当者のいないツールは、誰も見ないダッシュボードを生むだけです。

CRACIの役割

CRACIは、GitHub Actionsでビルドするソフトウェアについて、ステップ1と2、そしてステップ3と4の一部を自動化します。GitHubホストランナーを置き換え、各ジョブの実行中に、CIキャッシュから復元されたパッケージや、どのロックファイルにも載らない隠れた依存関係を含め、ジョブが実際に取得したパッケージを記録します。

• すべてのビルドからSBOM。各ジョブのSBOMはすべてのコンポーネントをPURLで識別し、完全性の状態を持つため、何かが見えなかった場合にそれがわかります。ビルド履歴には過去のすべてのビルドがSBOMとともに残るため、脆弱な依存関係を直接または推移的に含んでいたビルドを確認できます。
• 継続的な照合。監視対象のSBOMは継続的に再評価され、検出結果はビルドとリポジトリをまたいで集約されます。そのため、共有ライブラリのCVEは40件ではなく1つの問題として表示されます。
• 通知とゲート。CRACIは脆弱性とその深刻度を関係者に通知し、ポリシーゲートは特定のCVEを含むビルドを含め、ビルドをリアルタイムで停止できます。
• トリアージと割り当て。セキュリティチームはCRACIで検出結果をトリアージし、それぞれを修正を担当するチームに割り当てます。
• 機械可読なSBOM。SBOMはCycloneDXまたはSPDXでエクスポートでき、CRACIはVEXに対応しています。

CRACIはアドバイザリを公開せず、到達可能性分析を提供せず、自社コードのスキャンも行いません。料金はビルド時間のみで、vCPU分あたり$0.002（デフォルトの2 vCPUランナーでは$0.004）を秒単位で計量します。月額料金、SBOMごとの料金はなく、現在はライセンス料もかかりません。料金をご覧ください。

最初の2つのステップを今日から自動化しましょう：ビルドをCRACIで実行する。一般提供の開始前は、すべてのチームを個別にオンボーディングしています。

CRACIが適さない場合

• ソフトウェアをGitHub Actionsでビルドしていない場合。GitLab CIとJenkinsはロードマップにあります。
• リスクの対象が主にインフラ（サーバー、エンドポイント、クラウド設定）である場合。インフラ向けの脆弱性管理ツールのほうが適しています。
• 自社でビルドしないサードパーティのファームウェアを組み込んでいる場合。バイナリ解析ツールのほうが適しています。
• バックログの大半が、自社コードにある本物の悪用可能な検出結果である場合。それは自動化ではなく、修正能力の問題です。

脆弱性管理の自動化：よくある質問

なぜCVEの件数はこれほど増えているのですか？

CVEを採番する組織が増え、なかには広く採番する組織もあるためです。Linuxカーネルは2024年にCVE Numbering Authorityになり、脆弱性の可能性があるバグ修正すべてにCVEを割り当てています。AIを活用したツールにより、研究者1人あたりが発見するバグも増えています。2025年には47,801件のレコードが公開され、2026年は1日あたり303件のペースです。この傾向は何年も続いています。

小規模チームはどうすれば新しいCVEに追いつけますか？

読まないことです。すべてのビルドでSBOMを生成し、新しいCVEを保存済みのすべてのSBOMと自動で照合し、ノイズを削減して、残ったものについての判断だけを人が行います。小規模チームが追いつく方法は、速く働くことではなく、CVEごとに繰り返される手順をなくすことです。

脆弱性管理で最初に自動化すべきものは何ですか？

インベントリです。すべてのリリースビルドでCIがSBOMを生成し、リリースと一緒に保存します。後続のすべてのステップがこれに依存し、「影響を受けているか」がエンジニアリングへの質問から検索1回で答えられる問いに変わります。次がそれらのSBOMとの継続的な照合です。

脆弱性に対応するにはセキュリティチームが必要ですか？

最初は必要ありません。インベントリ、照合、ノイズ削減が自動化されていれば、プロセスを兼任で担当する1人で運用できます。チームよりも、明確な担当者と期限のほうが重要です。自社コードの修正や顧客向けのセキュリティ業務が仕事の中心になったら、採用を検討しましょう。

新しいCVEのうち、どれが自社製品に影響するかはどうすればわかりますか？

出荷したすべてのバージョンのSBOMを保存し、新しいCVEが公開されるたびに、複数の脆弱性情報源と照らしてすべてを再確認します。実際に出荷しているコンポーネントとバージョンに一致すれば、そのCVEは影響します。それが重要かどうかは、悪用可能性のコンテキストとVEXが示します。

SBOM、VEX、アドバイザリの「機械可読」とは何を意味し、なぜ重要なのですか？

ツールが解析できる標準の構造化形式のことです。SBOMはCycloneDXまたはSPDX、「影響なし」の声明はVEX、アドバイザリはCSAFです。顧客のスキャナーは誰も読まずにそれらを自社のインベントリと照合できるため、一度下した判断をすべての顧客とツールが再利用できます。

トリアージはどこまで安全に自動化できますか？

事実の収集です。深刻度、悪用の状況、そのコンポーネントを含む製品とバージョン、担当者、優先度の提案、期限。判断そのものは人が行うべきです。理由を記録せずに、検出結果を自動で「影響なし」として閉じてはいけません。

CriticalなCVEにはどれくらいの時間で対応する必要がありますか？

多くのプロセスが想定するより短い時間です。MandiantのM-Trends 2026は、2025年の平均悪用所要時間をマイナス7日、つまりパッチが存在する前に悪用されていると推定しています。EUのCyber Resilience Actのもとでは、積極的に悪用されている脆弱性について24時間以内に早期警告が必要です。深刻度と悪用状況に応じて自社の期限を定め、それに照らして測定しましょう。