脆弱性情報の収集を自動化する実務フロー

脆弱性情報の収集を自動化しても、届いたCVEをすべて同じ優先度で扱うと運用は詰まります。IPAの集計では、2026年4〜6月だけでJVN iPedia日本語版に13,131件が登録され、累計は290,167件になりました。更新量が多いほど、自社で使う製品か、悪用が確認されているか、止められない業務に影響するかを分けて見る必要があります。

この記事では、公開情報の定期収集から人の対応判断までをつなぐ実務フローを整理します。対象は、小規模なSaaSやITチームで脆弱性情報の確認を兼務する開発責任者、情シス、セキュリティ担当者です。

まず結論: 収集より先に「自社に関係するか」を判定できる形を作る

• 製品名、バージョン、利用場所、担当者を資産台帳から引けるようにする
• JVNやベンダーアドバイザリ、CISA KEV、NVDなどを役割別に分ける
• 資産該当性、悪用実績、技術的深刻度、事業影響の順で仕分ける
• 即時確認と週次レビューを分け、同じ情報を何度も通知しない
• AI要約は根拠整理に使い、パッチ適用やリスク受容は担当者が原文と環境を確認して決める

Stratum Flowが担えるのは、公開ページの定期確認と根拠URL付きレポートの作成です。端末やサーバーのスキャン、SBOMとの照合、侵害検知、緊急アラートの代わりにはなりません。

なぜ脆弱性情報は「件数順」で処理できないのか

IPAの2026年第2四半期集計では、JVN iPedia日本語版への新規登録13,131件のうち13,011件がNVD由来でした。公開件数をそのまま受信箱へ流すだけでは、自社に関係しない製品や重複更新が大半を占めます。

さらに、単一のスコアだけでは対応順を決められません。

• FIRSTのCVSS v4.0 User Guideは、Base Scoreが脆弱性の深刻度を表すもので、単独でリスク評価に使うべきではないと説明しています。
• CISAのKnown Exploited Vulnerabilities Catalogは、実際に悪用が確認された脆弱性を優先順位付けの入力として使うための一覧です。
• FIRSTのEPSSは、CVEが今後30日以内に悪用される確率を日次で推定します。ただし、自社の利用有無や事業影響までは判断しません。

したがって、公開情報の収集と、自社環境に基づくリスク判断を分ける必要があります。

手順1: 監視対象を資産台帳につなぐ

最初に対象製品を10〜20件へ絞ります。社内の全ソフトウェアを一度に扱うより、インターネット公開系、認証、決済、開発基盤など、止まったときの影響が大きい範囲から始めます。

製品名だけでは、同じアドバイザリが自社に当たるか判断できません。版、構成、公開範囲、代替手段まで分かる状態が、収集自動化の前提です。

手順2: 情報源を4つの役割に分ける

一つのデータベースへ依存せず、情報源ごとの役割を決めます。

MyJVNのフィルタリング収集ツールは、登録済み製品や深刻度でJVN iPediaの情報を絞れます。大量データを機械連携する場合は、NVD Data FeedsのAPIや更新フィードなど、構造化データを扱う専用手段が向いています。

Stratum Flowは、ベンダーのアドバイザリ一覧、JVNのレポート一覧、官公庁の注意喚起など、公開ページの変更を同じ観点で週次要約したい場合に補助線として使えます。Seed URLは1ジョブにつき1件なので、Seed URLの使い方を参照し、役割の異なるソースはジョブを分けます。

手順3: 4段階でトリアージする

新しいCVEを見つけたら、スコア順ではなく次の順で確認します。

1. 資産該当性

製品、バージョン、構成、OS、モジュールが自社環境に当たるかを確認します。判断できなければ「該当なし」ではなく「要確認」にします。

2. 悪用状況

KEV掲載、ベンダーが確認した攻撃、公開された回避策など、一次情報で確認できる事実を記録します。EPSSを使う場合も、確率だけで対応を確定せず、資産該当性と合わせて見ます。

3. 技術的深刻度

CVSSの値とベクトル、攻撃経路、必要権限、利用者操作、機密性・完全性・可用性への影響を読みます。「Criticalだから即対応」と短絡せず、どの条件で攻撃が成立するかを残します。

4. 事業影響と対応可能性

外部公開の有無、扱うデータ、停止時の影響、代替策、修正版の有無、メンテナンス時間を確認します。ここで初めて、担当者と確認期限を決めます。

この期限は一般例です。自社のインシデント対応基準、契約、規制、システム重要度に合わせて置き換えてください。

手順4: 毎回同じ対応メモを作る

要約文だけでは、次の担当者が原文を読み直すことになります。以下の欄を固定します。

CVE / advisory ID:
Confirmed change:
Affected product and versions:
Our asset match: yes / no / unclear
Exploitation evidence: KEV / vendor-confirmed / not confirmed
Severity details: CVSS score and vector / attack conditions
Business impact:
Vendor fix or mitigation:
Owner and review due:
Primary source URL and publication date:
Checked at:

「修正版がある」と「自社で適用できる」は別の判断です。停止時間、互換性、緩和策の副作用は、システム担当者が確認します。

手順5: 脆弱性情報の収集を自動化し、通知先を分ける

脆弱性情報の収集を自動化するときは、通知の条件を先に決めます。

週次レポートには「新規」だけでなく、対象版、修正版、KEV掲載などの更新も含めます。NVDのmodifiedフィードも、新規公開と更新の両方を扱っています。脆弱性情報は公開後にも変わるためです。

そのまま使えるリサーチ指示

指定したベンダー公式アドバイザリ、JVN、CISA KEVの公開ページを確認し、
前回確認後に新規公開または更新された脆弱性情報を整理してください。

各項目を CVE / advisory ID、確認できた変更、対象製品・版、悪用確認、
CVSSと攻撃条件、修正版または緩和策、一次情報URLと公開日、未確認事項に分けてください。
対象製品リストに一致しない項目は除外し、版や構成が判断できない場合は「要確認」と書いてください。
KEV掲載やベンダーによる悪用確認は一次情報で確認し、二次記事だけを根拠にしないでください。
リスク受容やパッチ適用の結論は出さず、担当者が次に確認する内容を示してください。
該当情報がない場合も、確認したページ、対象期間、「該当なし」を記録してください。

出力形式を調整するときは効果的なリサーチ指示の書き方を使い、最初は1ベンダー、10製品以内、1週間で試します。

失敗しやすいポイント

1. CVSSの高い順にすべて通知する

CVSS Base Scoreは深刻度であり、自社の資産該当性や悪用状況を含む完全なリスク値ではありません。通知前に少なくとも製品・版と公開範囲を照合します。

2. 新規公開だけを見て更新を追わない

対象版、修正版、回避策、悪用情報は後から更新されることがあります。IDごとに前回値と確認日を残します。

3. AI要約をパッチ判断として共有する

要約は受付票です。ベンダー原文、実際の構成、変更手順、バックアップ、ロールバック条件は担当者が確認します。

4. 定期レポートを緊急監視に使う

週次ジョブは、即時対応が必要な脆弱性の唯一の検知経路には向きません。ベンダー通知、専用スキャナー、EDR、SIEM、インシデント対応手順と併用します。

Stratum Flowを使いやすい場面と使わない場面

Stratum Flowを使いやすいのは、次のような補助的な運用です。

• ベンダーや公的機関の公開ページを週次で同じ形式にまとめたい
• 新規CVEだけでなく、対象版や修正版の更新を根拠URL付きで残したい
• 開発、情シス、セキュリティの確認待ち項目を一枚の週報にしたい
• 監視ソースと確認期間を記録し、「該当なし」と見落としを区別したい

一方、インストール済み資産の自動検出、SBOM照合、リアルタイム侵害検知、自動パッチ適用には専用ツールが必要です。Stratum Flowで始める場合は、公式アドバイザリ一覧をSeed URLにし、対象製品、除外条件、出力欄をリサーチ指示へ書きます。ジョブ作成の操作はダッシュボードの機能と基本設定で確認できます。

まとめ

脆弱性情報の収集を自動化する目的は、CVEを大量に集めることではありません。資産該当性、悪用実績、技術的深刻度、事業影響を順に確認し、原文と自社環境を見られる担当者へ渡すことです。

次のアクション

1ベンダー・10製品以内の週次確認ジョブを無料で試す

関連記事

• API変更と開発者ドキュメントを監視する方法
• 法改正・ガイドライン改定の情報収集を自動化する方法
• サプライチェーンリスク情報を定点観測する方法