先に要点
- 脆弱性の情報源は役割が分かれています。CVE は脆弱性に番号を振る仕組み、NVD はそこに深刻度などを足すデータベース、KEV と EPSS は「実際に悪用されているか・されそうか」、JPCERT/CC・JVN・IPA は国内向けの注意喚起、GitHub Advisory Database・OSV は使っているパッケージ単位の情報です。
- 2026年4月から NVD は、KEV に載ったものなどを優先し、それ以外はすぐには情報を足さない方針に変わりました。NVD に深刻度が出るのを待つより、製品の提供元の告知を直接見るほうが速くなっています。
- 国内の JVN iPedia と MyJVN は2026年10月22日から一時停止中です（再開は未定。JVN 本体は通常どおり）。
- 全部を毎日見る必要はありません。JPCERT/CC のメーリングリスト、使っている製品の提供元の告知、KEV の更新、開発しているなら Dependabot や OSV のパッケージの通知、の組み合わせで足ります。
脆弱性の対応は、まず「知ること」から始まります。ところが情報源は CVE、NVD、KEV、JVN、ベンダーの告知と多く、どれを見ればよいのか分かりにくいのが実情です。2026年10月には、PHP の脆弱性と、圧縮形式 Brotli の脆弱性が、数日のうちに続けて米国の CISA の「実際に悪用が確認された脆弱性」の一覧に載りました。セキュリティ企業 Rapid7 の2026年第3四半期の報告では、深刻度の高い脆弱性が公開されてから悪用されるまでは平均3日で、追跡した悪用の71%が公開から7日以内に起きていました。
この記事では、CVE Program、NIST（NVD）、CISA、FIRST、JPCERT/CC、IPA、OSV、GitHub の公式ページ（いずれも2026年10月28日に確認）をもとに、各情報源の役割の違いと、社内の IT 担当や開発者が何を購読すればよいかを整理します。悪用の状況から対応の優先度を決める方法は KEVカタログで脆弱性対応の優先度を決める で詳しく解説しています。
情報源の地図：番号・深刻度・悪用・国内・パッケージ
ひとつの脆弱性が公表されると、いくつもの情報源に、それぞれの役割に応じた形で載っていきます。
| 情報源 | 運営 | 何が分かるか | 受け取り方 |
|---|---|---|---|
| 製品の提供元の告知 | 各社・各プロジェクト | 影響を受ける版、修正版、回避策 | 各社のセキュリティ告知のページ、メール、RSS |
| CVE | CVE Program（CISA が後援、MITRE が運営） | 脆弱性の識別番号と、CNA が書いた説明・参照先 | cve.org で番号を検索 |
| NVD | NIST | CVSS の深刻度、対象製品の一覧（CPE）など | Web と API 2.0、データフィード 2.0 |
| KEV | CISA | 実際に悪用が確認された脆弱性と対応の期限 | JSON・CSV、メールでの更新通知 |
| EPSS | FIRST | 今後30日に悪用される確率の推定 | 毎日の CSV、API（無料・登録不要） |
| JPCERT/CC の注意喚起・Weekly Report | JPCERT/CC | 国内で特に注意が要る脆弱性、前の週の要点 | メーリングリスト、RSS |
| JVN | JPCERT/CC と IPA | 国内で調整して公表された脆弱性 | Web、RSS |
| 重要なセキュリティ情報 | IPA | 緊急・注意の2段階で示す、対策を急ぐべき情報 | Web、RSS |
| GitHub Advisory Database・OSV | GitHub、OSV（Google が始めたオープンソースの取り組み） | npm・PyPI・Maven などのパッケージの脆弱性 | Dependabot の通知、OSV の API・OSV-Scanner |
CVE と NVD：番号と、深刻度の付け足し
CVE は、公表された脆弱性を1件ずつ識別するための仕組みです。CVE ID（CVE-2026-111497 のような番号）は、CNA と呼ばれる認定を受けた組織が振り、説明や参照先をまとめた CVE レコードを公開します。CNA には製品の提供元自身が多く含まれ、cve.org の2026年10月27日のお知らせでは、43か国の563組織が CNA になっています。
CVE で分かること
どの製品のどんな脆弱性か、という説明と、提供元の告知などへのリンクです。CVE のブログが書くとおり、CVE ID は脆弱性を指す番号で、修正プログラムや告知の名前ではありません。対応の手順は、リンク先の提供元の告知で確かめます。
NIST は2026年4月15日、CVE の登録が2020年から2025年で263%増えたことを理由に、方針を変えました。KEV に載った CVE は受け取ってから1営業日以内を目標に情報を足し、連邦政府で使うソフトウェアや重要なソフトウェアの CVE も優先します。それ以外は「最も低い優先度（すぐには付け足さない）」に分類され、CNA がスコアを付けている CVE には、NVD が別のスコアを付けることも原則としてしなくなりました。NVD の深刻度が空欄だから軽い、ということにはならない点に注意します。
そのため、自分が使っている製品の脆弱性は、NVD に情報が付くのを待たずに、CVE レコードの CNA のスコアと、提供元の告知で判断するのが現実的です。CVE Program の運営体制は2025年に契約をめぐって不安視された時期がありましたが、CISA は後援を続けると表明しており、2026年10月時点でも CVE の採番と公開は続いています。
悪用されているかを見る：KEV と EPSS
CVSS は「悪用されたらどれだけ深刻か」を示す値で、「実際に悪用されているか」は分かりません。そこを補うのが KEV と EPSS です。
KEV（CISA）
CVE があること、実際に悪用された確かな証拠があること、修正版など明確な対処があること、の3つを満たした脆弱性の一覧です。2026年10月27日版で1,760件。米国の連邦政府機関には対応の期限があり、2026年6月の指令 BOD 26-04 以降、悪用の状況などに応じて3日・14日などに分かれています。
EPSS（FIRST）
公開済みの CVE ごとに、今後30日のあいだに悪用される確率を推定した値です。毎日すべての CVE について更新され、2026年6月15日からは新しいモデル（v5）で計算されています。KEV に載る前の段階で、優先度を考える材料になります。
KEV は JSON で公開されているので、新しく載ったものを機械的に拾えます。次は、2026年10月26日以降に追加されたものを出す例です（Linux のサーバーで jq を使って実行した結果）。
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
| jq -r ".vulnerabilities[] | select(.dateAdded >= \"2026-10-26\") | \"\(.dateAdded) \(.cveID) \(.product)\""
# 2026-10-27 CVE-2026-48356 Commerce and Magento
# 2026-10-27 CVE-2026-111497 Brotli
# 2026-10-26 CVE-2026-109618 PHP
# 2026-10-26 CVE-2026-109619 PHP
KEV の更新は CISA のページからメールで受け取ることもできます。期限の読み方や、自社の機器の一覧との突き合わせ方は KEV の記事 を見てください。
国内の情報源：JPCERT/CC・JVN・IPA
日本語で、国内の製品や国内で広く使われているソフトウェアの情報を得るなら、次の3つです。
| 情報源 | 中身 | 購読の方法 |
|---|---|---|
| JPCERT/CC の注意喚起 | 深刻で影響の広い脆弱性などを知らせる文書。2026年10月は PHP と Brotli（HTTP2Shell）の脆弱性について出ている | メーリングリスト（登録の方法は JPCERT/CC のメーリングリストのページに案内がある）、RSS（jpcert.rdf） |
| JPCERT/CC の Weekly Report | 前の週の情報のうち、JPCERT/CC が重要と判断したものの抜粋。通常は水曜日 | 同じメーリングリストと RSS |
| JVN | JPCERT/CC と IPA が共同で運営。国内の届出の制度で調整した脆弱性や、海外の機関と調整したものを公表 | Web、RSS（jvn.rdf など） |
| IPA の重要なセキュリティ情報 | 対策を急ぐべき情報を「緊急」「注意」で示す。Microsoft の月例の更新なども載る | Web、RSS（alert-rss.rdf） |
JPCERT/CC は2026年10月22日、システムの保守のため JVN iPedia と MyJVN を一時停止していると告知しました。再開の時期は未定で、再開までは新しく公表する JVN のアドバイザリに JVN iPedia へのリンクを載せないとしています。JVN 本体は通常どおり使えます。MyJVN の API やバージョンチェッカを業務の確認に使っている場合は、代わりの手段を考えておきます。
社内の IT 担当が1つだけ選ぶなら、JPCERT/CC のメーリングリストが始めやすい選択肢です。注意喚起と Weekly Report の両方が届くので、重大なものは当日、それ以外は週1回まとめて把握できます。
使っているパッケージを調べる：GitHub Advisory Database と OSV
開発しているアプリが使うライブラリの脆弱性は、パッケージの名前と版で調べる情報源が向いています。
GitHub Advisory Database と Dependabot
npm・PyPI（pip）・Maven・Composer・Go・RubyGems・NuGet・Rust などのパッケージの脆弱性を集めたデータベースです。GitHub の担当者が確認した情報が載ると、リポジトリの依存に当てはまる場合に Dependabot の通知が届きます。悪意のあるパッケージの情報も載ります。
OSV
GitHub のアドバイザリや PyPI の情報など、複数のデータベースを共通の形式（OSV 形式）で集めたものです。Debian・Ubuntu・Alpine など OS のパッケージも含め、約40のエコシステムを扱います。API と、依存を一括で調べる OSV-Scanner があります。
OSV の API には、パッケージの名前と版を送るだけで問い合わせられます。次は、Python の brotli パッケージの 1.1.0 を調べた例です。2026年10月の HTTP2Shell（CVE-2026-111497）が、GitHub のアドバイザリの番号と一緒に返ってきます。
curl -s -d "{\"package\":{\"name\":\"brotli\",\"ecosystem\":\"PyPI\"},\"version\":\"1.1.0\"}" \
https://api.osv.dev/v1/query | jq -r ".vulns[] | \"\(.id) \(.aliases | join(\",\"))\""
# GHSA-2qfp-q593-8484 CVE-2025-6176,PYSEC-2026-1906,PYSEC-2026-2401
# GHSA-9v8h-qqgm-4m35 BIT-node-2026-111497,BIT-node-min-2026-111497,CVE-2026-111497,PYSEC-2026-4322,PYSEC-2026-4323
# （ほかに PYSEC で始まる行が2つ。同じ脆弱性を別のデータベースの番号で表したもの）
1つの脆弱性に、CVE・GHSA（GitHub）・PYSEC（PyPI）など複数の番号が付くのはよくあることです。aliases（別名）でつながっている番号は同じ脆弱性なので、二重に数えないようにします。
何を購読するか：役割ごとの組み立て
情報源を全部追いかける必要はありません。自分が守る範囲に合わせて、少数を確実に見るほうが漏れが減ります。
| 立場 | 購読するもの | 見る頻度の目安 |
|---|---|---|
| 社内の IT 担当（少人数） | JPCERT/CC のメーリングリスト、IPA の重要なセキュリティ情報の RSS、使っている製品（OS・VPN 機器・ファイアウォール・グループウェアなど）の提供元の告知、KEV の更新メール | 注意喚起・緊急はその日、ほかは週1回 |
| Web アプリの開発者 | 使っている言語とフレームワークの公式のセキュリティ告知、Dependabot の通知か OSV-Scanner、KEV の更新 | 通知が来たとき、加えて週1回 |
| サーバーの運用担当 | OS のディストリビューションのセキュリティ告知（Ubuntu・Debian・RHEL など）、ミドルウェア（Web サーバー・DB・DNS）の告知、JPCERT/CC | 注意喚起はその日、ほかは週1回 |
週1回の確認の流れ（例）
- 1届いた通知を開く
JPCERT/CC の Weekly Report、提供元の告知、Dependabot の通知をまとめて見る。
- 2自分の一覧と突き合わせる
使っている製品・版の一覧（資産の台帳や SBOM）と照らして、当てはまるものだけ残す。
- 3悪用の状況で順番を決める
KEV に載っているもの、外部に公開している機器のものを先にする。EPSS が高いものも前に出す。
- 4対応と記録
更新の予定日を決め、済んだら版を記録する。すぐに更新できないものは回避策と見直しの日付を書いておく。
どれだけ情報を集めても、自分が何をどの版で使っているかが分からなければ、当てはまるかを判断できません。機器とソフトウェアの一覧、開発なら依存の一覧（SBOM や lock ファイル）を先に用意しておくことが、情報収集を役立てる前提になります。
実際の例として、Laravel の TokenGuard の脆弱性（CVE-2026-114509）は、GitHub のアドバイザリで公表され、数日後に JPCERT/CC の Weekly Report にも載りました。自分のアプリが対象かを確かめる流れは、この記事が実例になります。
よくある質問
NVD に CVSS のスコアが出ていない脆弱性は、後回しでよいですか？
いいえ。2026年4月から NVD は KEV に載ったものなどを優先し、それ以外にはすぐに情報を足さない方針です。スコアが無いのは、NVD がまだ手を付けていないだけのことがあります。CVE レコードにある CNA のスコアと、提供元の告知で深刻度を確かめます。
JVN と NVD はどう違いますか？
JVN は、JPCERT/CC と IPA が運営する国内向けの脆弱性情報のサイトで、国内の届出の制度で調整した脆弱性などを日本語で公表します。NVD は米国の NIST が運営し、世界中の CVE に深刻度などを付け足すデータベースです。国内の製品や国内で調整された脆弱性は、JVN のほうが詳しいことがあります。
KEV に載っていない脆弱性は安全ですか？
安全とは限りません。KEV は、悪用の確かな証拠がそろったものだけを載せる一覧なので、悪用が始まってから載るまでに時間差があります。外部に公開している機器や、深刻度が高く修正版が出ているものは、KEV を待たずに更新します。EPSS の値も手がかりになります。
情報収集を AI に任せてもよいですか？
要約や一覧の整理に使うのは便利ですが、影響を受ける版や修正版の番号は、必ず提供元の告知で確かめます。脆弱性の情報は公表後に何度も更新されることが多く、古い情報や似た名前の別の脆弱性と取り違えると、対応を誤ります。
集めた情報を月ごとに並べた例として、2026年のセキュリティ更新の記録があります（修正から KEV 追加までの日数も比べています）。
まとめ
- CVE は番号、NVD は深刻度の付け足し、KEV と EPSS は悪用の状況、JPCERT/CC・JVN・IPA は国内向け、GitHub Advisory・OSV はパッケージ単位、と役割が分かれている
- NVD は2026年4月から KEV に載ったものなどを優先するので、深刻度は CNA のスコアと提供元の告知で確かめる
- JVN iPedia と MyJVN は2026年10月22日から一時停止中（JVN 本体は通常どおり）
- 社内の IT 担当は JPCERT/CC のメーリングリストと提供元の告知、開発者は Dependabot か OSV、どちらも KEV の更新を加えると、少ない購読で漏れを減らせる
- 情報を役立てる前提は、自分が何をどの版で使っているかの一覧
参考リンク
- CVE Program: Overview・Glossary
- Statement from Matt Hartman on the CVE Program（CISA、2025年4月23日）
- National Vulnerability Database: NVD Operations Update（NIST、2026年4月15日ほか）
- Reducing the Significant Risk of Known Exploited Vulnerabilities（CISA）・KEV Catalog
- BOD 26-04: Prioritizing Security Updates Based on Risk（CISA、2026年6月10日）
- EPSS（FIRST）・EPSS のデータとモデルの版
- JPCERT/CC メーリングリスト・JPCERT/CC RSS
- JVN とは・JVN iPedia、MyJVN サービスの一時停止のお知らせ（2026年10月22日）
- IPA 重要なセキュリティ情報
- OSV・About the GitHub Advisory Database
- Rapid7 Quarterly Threat Landscape Report