脆弱性の知らせの読み方：CVE・CVSS 4.0・KEV と、npm audit・Dependabot の限界

脆弱性（ソフトウェアの弱点）の知らせに付く「9.8 CRITICAL」のような点は、その脆弱性の深刻度（ほかの脆弱性と比べた、問題の重さ）を表すもので、あなたのシステムが受けるリスク（被害の起こりやすさと大きさ）ではありません。CVSS（脆弱性の深刻度を点で表す仕組み）の仕様を出している FIRST は、Base（基本）の点だけでリスクを測ってはいけないと、はっきり書いています。

もう一つ、npm audit が「found 0 vulnerabilities（脆弱性は 0 件）」と言ったときの意味は、npm の文書によると「知られた脆弱性のあるパッケージが、依存の木の中に見つからなかった」ということです。「安全です」とは書かれていません。

この記事は、npm install や GitHub を使い始めた初心者〜若手の人に向けて、脆弱性の知らせに出てくる言葉（CVE・CVSS 4.0・NVD・KEV・JVN・GitHub の告知・EPSS）を読み解き、npm audit と Dependabot（GitHub の、依存の脆弱性を知らせてくれる機能）が教えてくれること・教えてくれないことを整理します。手元の npm audit --json の出力も、そのまま載せて読みます。セキュリティ全体の点検は、Web 開発のセキュリティの基本にまとめています。

書いてあることは、各機関の文書を2026年10月21日に開いて確かめたものです。手元の確かめは macOS 14.4.1・Node.js 24.21.0・npm 11.19.0 で流しました。点数・件数・一覧に載っているかは日々変わるので、数字には日付を添えました。

この記事でわかること

CVE・CVSS・NVD・KEV・JVN・GitHub の告知・EPSS が、それぞれ「何を、誰が出すものか」
CVSS-B は深刻度であってリスクではないこと。KEV は「悪用の確かな証拠がある」一覧で、EPSS と CVSS は掛けないこと
npm audit --json の読み方と、--force の注意、「0 件」の意味
npm audit と Dependabot が教えてくれないこと

脆弱性の知らせにはどんな種類がある？全体の地図
CVE・NVD・JVN・GHSA とは？番号と告知を出す所
CVSS 4.0 の点は何を表す？深刻度であって、リスクではない
KEV とは？ EPSS との違いと、CVSS と掛けてはいけない理由
npm audit は何を教えてくれる？出力の読み方と、fix・--force の違い
npm audit が教えてくれないことは？
Dependabot alerts が教えてくれないことは？
1. 公式の Limitations（5 つ）
2. 有効にした直後は、既存の脆弱性のお知らせ（メール）を全部は送らない
よくある質問
1. npm audit が 0 件なら、安全ですか？
2. npm audit fix --force を付けて直してよいですか？
まとめ
参考資料

脆弱性の知らせにはどんな種類がある？全体の地図

まず、名前を整理します。同じ脆弱性の知らせでも、出す組織と、書いてあることが違います。

名前	何か	出している所
CVE	公に知らされた脆弱性に、番号（CVE ID）を付けて一覧にする仕組み	CVE Program（米国の CISA が後ろ盾、運営は MITRE の研究開発センター）
CVSS	脆弱性の深刻度を点で表す仕組み。いまは 4.0	FIRST
NVD	CVE の一覧に情報を足したデータベース。CVSS の点も付く	米国の NIST
KEV	悪用が確認された脆弱性の、正式な一覧	米国の CISA
JVN / JVN iPedia	日本で使われるソフトの脆弱性と対策の情報	JPCERT/CC と IPA
GitHub Advisory Database（GHSA）	オープンソースのパッケージの、脆弱性とマルウェアの告知の一覧	GitHub
EPSS	CVE が「この先 30 日に悪用される確率」の見積もり	FIRST の EPSS SIG が保守

この表のうち、KEV だけが「悪用された」という過去の記録で、EPSS は予測、CVSS は深刻度です。どれも「あなたのシステムが危ないか」を、そのままは答えてくれません。npm audit と Dependabot は、これらの情報を読む側のツールです。

CVE・NVD・JVN・GHSA とは？番号と告知を出す所

CVE Program の目的は、公に知らされたセキュリティの脆弱性を見つけ、定め、一覧にすることです（cve.org）。脆弱性 1 つに、CVE Record が 1 つあり、番号の形は CVE-YYYY-NNNN です。番号を割り当てて公開するのは、CNA（CVE Numbering Authority）という組織です。CNA は CVE Program に認められた組織で、自分の受け持ちの範囲の中で CVE ID を割り当てます。ベンダー（製品を作る会社）・研究者・オープンソースなどがあり、料金も契約も要りません。GitHub も CNA で、JPCERT/CC も CNA です（日本の組織をまとめる Root でもあります）。JPCERT/CC の注意喚起は、JPCERT/CC の注意喚起（2026年10月）を読み解くで扱っています。

CVE と NVD は別の仕組み

cve.org の FAQ は、はっきり書いています。CVE と NVD は別々のプログラムです。CVE の一覧が NVD に流れ込み、NVD がこれまで各レコードに情報を足してきました。NVD の FAQ によると、NVD は CVE の公開にはかかわらず、CVE の一覧に出てから、たいてい 1 時間以内に NVD に載ります。IPA の古い概説（2015年）には「MITRE社が採番」とありますが、いまの cve.org は「CNA が自分の範囲で割り当てて公開する」と説明しています。この記事は cve.org の側で書いています。

CVE の番号が無い知らせもある

GitHub の告知（GHSA）では、React と Next.js の 5 件のうち、CVE があるのは 1 件だけでした（2026年10月19日時点。React と Next.js の脆弱性の記事の表の写しです）。CVSS も、CVE の番号や Record が無くても使えます（FIRST の FAQ）。CVE Record に CVSS の点を入れるかどうかは任意です（cve.org の FAQ。CNA が入れられる欄があります）。

JVN と JVN iPedia：日本語で読める知らせ

JVN は "Japan Vulnerability Notes" の略で、日本で使われているソフトウェアなどの脆弱性と対策の情報を出すポータルサイトです。「情報セキュリティ早期警戒パートナーシップ」に基づいて、2004 年 7 月から JPCERT/CC と IPA が共同で運営しています。パートナーシップで届けられて調整した脆弱性と、CERT/CC など海外の調整機関と連携した脆弱性が載り、対策にはパッチだけでなく回避策（ワークアラウンド）が載ることもあります。攻撃がすでに観測されているなど、対策の順番を決めるのに大事な補足があるときは「緊急」と表示されます。

CVSS の版には食い違いがあります。JVN の「脆弱性レポートの読み方」（最終更新日 2024/10/01）は「CVSS v3 および CVSS v2 の Base Score を用いて脆弱性を評価しています」と書きますが、2026-10-20 公開のレポート 2 件は CVSS 4.0 と 3.0 の基本値（Base）を並べていました。どちらも Base なので、リスクではなく深刻度です。

IPA の JVN iPedia は、2007-04-25 から日本語で公開している脆弱性対策情報のデータベースで、国内の開発者の情報・JVN・NVD の情報を集めて訳しています。登録の累計は 310,240 件です（2026-09-30 までの累計。IPA の 2026年第3四半期の報告、2026-10-21 公開）。2026年10月21日に開いたときは「メンテナンス中」で、検索画面の使い方は確かめられませんでした。

GitHub Advisory Database と GHSA

GitHub Advisory Database は、オープンソースのパッケージの、脆弱性とマルウェア（悪意のあるプログラム）の告知を集めた一覧です。告知は OSV という形式の JSON で、ID は GHSA-xxxx-xxxx-xxxx の形です。出どころは、GitHub に報告された告知・NVD・npm の告知のデータベース・各言語のデータベース（Go・Python・Ruby・Rust など）・コミュニティの寄稿です。

大事なのは、GitHub が確かめた告知（reviewed）と、確かめていない告知（unreviewed）があることです。unreviewed は NVD の配信からそのまま自動で入ります。Dependabot は unreviewed の告知では通知を作りません（GitHub Docs）。告知には CVSS 3.1 と 4.0 が使え、CVE と EPSS のデータがあれば EPSS の値も載ります。マルウェアの告知には、直った版がありません。安全な版が無いので、そのパッケージを使わないことだけが手です。Dependabot のマルウェアの通知は、有効にしたときだけ作られます。

CVSS 4.0 の点は何を表す？深刻度であって、リスクではない

CVSS は、脆弱性の技術的な特徴を表し、ほかの脆弱性と比べた深刻度を点で出す仕組みです（FIRST の仕様）。4.0 の仕様は v1.2（2024-06-18）が最新で、FAQ はいまも足されています（v1.10、2026-07-17）。

4 つの群：Base・Threat・Environmental・Supplemental

群	何を表すか	誰が付けるか
Base	時間でも環境でも変わらない、脆弱性そのものの性質。環境ごとの「ありうる最悪」を前提にする	作った側、または代わりの第三者
Threat	時間で変わること（攻撃された、攻撃の試作が出たなど）。Exploit Maturity の値は Attacked・Proof-of-Concept・Unreported・Not Defined	使う側
Environmental	使う側の環境（守りの仕組みがあるか、そのシステムがどれだけ大事か）	使う側
Supplemental	点には効かない補足の情報	作った側、または代わりの第三者

Threat と Environmental は、使う側しか分かりません（仕様）。Threat が Not Defined（既定）のときは、計算では最悪の Attacked と同じに扱います。

点には、使った群が分かる名前を添える決まりです。CVSS-B（Base）・CVSS-BE（Base と Environmental）・CVSS-BT（Base と Threat）・CVSS-BTE（3 つ全部）です。作った側や NVD などが出すのは、普通は Base だけの CVSS-B です。Threat と Environmental を当てはめるのは、使う側の責任です（仕様・User Guide）。NVD も Base だけを付けています。

分かりにくい点が 1 つあります。4.0 では、選ばなくても既定の値（Not Defined）で計算に入るので、点はいつも 1 つです。名前は「どの群を明示して選んだか」を示すためのものです（FAQ）。言葉での格付けは、None 0.0・Low 0.1〜3.9・Medium 4.0〜6.9・High 7.0〜8.9・Critical 9.0〜10.0 です。

ベクター文字列

点と一緒に出る CVSS:4.0/AV:N/… のような文字列を、ベクター文字列と呼びます。FIRST は、CVSS を出す人に、点とベクター文字列の両方を出すことを求めています。仕様の例です。

CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:A

2 行目は、1 行目に Exploit Maturity: Attacked を足したもので、末尾に /E:A が付きます。各項目の値の読み方は、FIRST の仕様を見てください。

CVSS-B は深刻度で、リスクではない

ここが、この記事でいちばん伝えたいことです。FIRST の User Guide の見出しは「CVSS Base Score (CVSS-B) Measures Severity, not Risk」です。CVSS-B は脆弱性の深刻度を測るもので、単独でリスクの判断に使ってはいけません。環境（Environmental）と、時間で変わる性質（Threat）で補うと、CVSS-BTE は「リスク」にずっと近づきます。NVD の CVSS のページも「CVSS is not a measure of risk」と書いています。

パッチ（直した版）を入れる順番も同じです。FAQ（v1.9 で足された項目）は「CVSS-B は単独でパッチの優先順位に使ってはいけない」と書き、優先順位の付け方の手本として CISA の BOD 26-04（後で説明します）を挙げています。規制・影響を受ける顧客の数・お金の損・評判などは CVSS の範囲の外で、使う側が別に考えます（仕様）。

同じ脆弱性なのに点が違うのはなぜ？

1 つの脆弱性に、出す人によって違う点が付くことがあります。FIRST の FAQ は、意図した違い・直し・間違いのどれもありうるので、どこが付けた点かを見て決める、と書いています。「どちらが正しい、とは決めない」場合もあります。

手元で NVD の API を引いた例です（Trivy の件、CVE-2026-33634。2026年10月21日の値。サプライチェーン攻撃の記事で扱った件です）。

項目	NVD が付けた点	GitHub（CNA）が付けた点
CVSS の版	3.1	4.0
点	8.8 HIGH	9.4 CRITICAL

版も出した組織も違うので、点が違っても不思議ではありません。どちらかに揃えず、「どこが、どの版で付けた点か」を見ます。反対に、4.0 の点が無い例もあります。minimist（JavaScript のコマンドライン引数を読む部品）の CVE-2021-44906 は、NVD が 3.1 で 9.8 CRITICAL を付けていますが、4.0 の点は NVD のデータにありません。

NVD の CVE の中には、いまは情報を足す予定が無いもの（状態 Not Scheduled、API では Deferred）もあります。NVD の CVSS のページの「全部の CVE に付ける」という意味の文とは食い違うので、NVD が情報を足していない CVE もある、と考えて読むほうが安全です。

KEV とは？ EPSS との違いと、CVSS と掛けてはいけない理由

KEV（Known Exploited Vulnerabilities Catalog）は、CISA が持つ、悪用された脆弱性の正式な一覧です。CISA は、どの組織も、KEV を直す順番を決める枠組みの材料の 1 つに使うよう書いています。

KEV に載る条件は 3 つ

CVE ID がある
現実の攻撃で悪用された確かな証拠がある（reliable evidence that the vulnerability has been actively exploited in the wild）
直し方がはっきりしている（ベンダーの更新など）

「悪用されやすさ」は条件ではなく、悪用された・されているかどうかです。試みた（成功しなかった）攻撃は含みますが、スキャン・攻撃手法の研究・PoC（動作を示す試作）は悪用に数えません。条件から言えることが 1 つあります。KEV に載っていないことは、「悪用されていない」の証明ではありません。CVE ID が無いものや、確かな証拠が集まっていないものは載りません。

KEV の JSON の版 2026.10.20（2026-10-20 に出た版）には、1754 件が載っていました。ほかの記事で出てきた Log4j・tj-actions/changed-files・Trivy の件は、どれも載っています（載った日は順に 2021-12-10・2025-03-18・2026-03-26）。一方、minimist の CVE-2021-44906 は、CVSS 3.1 で 9.8 CRITICAL ですが、この版の KEV には載っていません。点が高いことと、悪用が確認されていることは、別の問いです。

KEV の扱いは、2026-06-10 に出た BOD 26-04（CISA の拘束力のある運用指令）に移りました。載る条件は BOD 22-01 のものを引き継いでいます。米国の連邦の行政機関は、期限までに直す義務があります。それ以外の組織は縛られませんが、CISA は KEV を優先して直すよう強く勧めています。BOD 26-04 そのものは、この記事では開いていません。

EPSS は予測、KEV は記録

EPSS（Exploit Prediction Scoring System）は、公開された CVE がこの先 30 日に悪用される確率を見積もる、機械学習のモデルです。毎日、すべての CVE に 0〜1 の確率（とパーセンタイル、つまり順位）を出し、無料で公開しています。FIRST の説明では、KEV は悪用が確認された「過去の記録」、EPSS は「この先の予測」で、別の問いです。目安は、KEV に載っているものは、EPSS が低くても、悪用されているものとして優先するです。

EPSS は、深刻度の点でも、完全なリスクの点でもありません。被害の大きさも、自分の環境に当たるかも測りません（FIRST）。手元の例では、minimist の CVE-2021-44906 の EPSS は、FIRST の API の2026-10-20 の値で、確率 0.04581（約 4.6%）、パーセンタイル 0.915 でした。日ごとに変わる数字です。なお、GitHub Docs の例の「90.534%、95 パーセンタイル」は説明のために作られた数で、実際の値ではありません。

EPSS と CVSS は掛けない

FIRST の「EPSS の使い方」は、よくある誤用として、EPSS の点に CVSS を掛けて「合わせたリスクの点」を作らないことを挙げています。EPSS は調整された確率ですが、CVSS は経験的な調整の無い順位付けなので、掛けた数には解釈できる意味が無い、という説明です。

npm audit は何を教えてくれる？出力の読み方と、fix・--force の違い

npm の文書によると、npm audit は、プロジェクトの依存の一覧を、既定の registry（パッケージを置いている公開の場所）に送って、知られた脆弱性の報告をもらうコマンドです。見つかると 0 以外の終了コードで終わります。既定では package-lock.json（入れた版を固定して記録するファイル）が要ります。送るのは、木の中の各パッケージの名前と版の一覧です。--omit で外した種類は送りません。npm install のたびに audit も動き、--no-audit で止められます。

npm audit の情報源について、言えること・言えないこと

「npm audit は GitHub Advisory Database を見ている」とは、この記事では言い切りません。npm の文書は「既定の registry に送る」「advisory database」と書くだけで、GitHub の名前を書いていないからです。確かめたことは、次の 3 つまでです。

手元の出力に出る告知の URL は、https://github.com/advisories/GHSA-… の形だった
GitHub の文書は、Advisory Database の告知の出どころの 1 つに「npm の告知のデータベース」を挙げている
全体の Advisory Database に無い React・Next.js の 5 件の告知は、2026年10月19日の時点で npm audit に出なかった

決め打ちの版で入れて、npm audit を流す

空のフォルダーで、知られた脆弱性のある古い版の minimist（悪意のあるパッケージではありません）を、版を決め打ちして入れました。本番の package.json では試さず、使い捨てのフォルダーで流してください。スクリプトが動かないよう、--ignore-scripts を付けています。脆弱性を突く操作はしていません。

$ npm init -y >/dev/null
$ npm install minimist@1.2.5 --save-exact --ignore-scripts

added 1 package, and audited 2 packages in 462ms

1 critical severity vulnerability

To address all issues, run:
  npm audit fix --force

Run `npm audit` for details.
[exit 0]

[exit N] は終了コードを、後から足した行です。npm install は、脆弱性を見つけても終了コード 0 で終わりました。install の中の audit は、止めません。CI で止めたいときは、npm audit を別に流す必要があります。

$ npm audit
# npm audit report

minimist  1.0.0 - 1.2.5
Severity: critical
Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h
fix available via `npm audit fix --force`
Will install minimist@1.2.8, which is outside the stated dependency range
node_modules/minimist

1 critical severity vulnerability

To address all issues, run:
  npm audit fix --force
[exit 1]

読み方です。

1 行目の minimist 1.0.0 - 1.2.5 は、パッケージ名と、脆弱性に当たる版の範囲です
Severity: の下に、告知の題と GHSA の URL があります。題の Prototype Pollution は、JavaScript のオブジェクトの土台を書き換えられる種類の問題の名前です
fix available via … が直し方です（この例は --force が要ると出ました。理由は後の節）。node_modules/minimist は入っている場所です

npm audit --json の読み方

機械で読むときは --json を付けます。同じフォルダーで流した出力です。

$ npm audit --json
{
  "auditReportVersion": 2,
  "vulnerabilities": {
    "minimist": {
      "name": "minimist",
      "severity": "critical",
      "isDirect": true,
      "via": [
        {
          "source": 1097678,
          "name": "minimist",
          "dependency": "minimist",
          "title": "Prototype Pollution in minimist",
          "url": "https://github.com/advisories/GHSA-xvch-5gv4-984h",
          "severity": "critical",
          "cwe": [
            "CWE-1321"
          ],
          "cvss": {
            "score": 9.8,
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H"
          },
          "range": ">=1.0.0 <1.2.6"
        }
      ],
      "effects": [],
      "range": "1.0.0 - 1.2.5",
      "nodes": [
        "node_modules/minimist"
      ],
      "fixAvailable": {
        "name": "minimist",
        "version": "1.2.8",
        "isSemVerMajor": false
      }
    }
  },
  "metadata": {
    "vulnerabilities": {
      "info": 0,
      "low": 0,
      "moderate": 0,
      "high": 0,
      "critical": 1,
      "total": 1
    },
    "dependencies": {
      "prod": 2,
      "dev": 0,
      "optional": 0,
      "peer": 0,
      "peerOptional": 0,
      "total": 1
    }
  }
}
[exit 1]

isDirect は自分の package.json に書いた直接の依存か、via は告知（title・url・severity・cwe〔弱点の種類の番号〕・cvss・range。パッケージ名の文字列なら meta-vulnerability で、後の節）、effects はこれのせいで脆弱と数えられた上の側の依存、fixAvailable は直し方（3 つの形。後の節）、metadata.vulnerabilities は重さごとの数です。

注意が 3 つあります。

range が 2 つあります。 via の中の range（>=1.0.0 <1.2.6）は告知に書かれた範囲、外の range（1.0.0 - 1.2.5）は実在する版に直した範囲です
cvss.vectorString は 3.1 のベクターです。この告知には、GitHub の側でも 4.0 の点が付いていません（後の節の gh api の出力）
source の数（1097678）は npm の側の告知の番号で、GHSA の ID ではありません

CI で使う --audit-level は、失敗にする最低の重さを変えるだけで、報告の中身は絞りません（npm の文書）。npm の文書は重さに目安（Critical はすぐ、High はできるだけ早く、Moderate は時間があるとき、Low は判断で）を付けますが、送るのは名前と版の一覧だけなので、あなたのシステムでの使われ方までは知りません。

ここからは直す側の話です。npm audit fix は、直せる脆弱性を自動で直そうとするコマンドです。npm の文書によると、中で本当の npm install を回し、自動で直せない脆弱性は手での確認が要ります。どこまで直すかは、package.json に書いた依存の範囲で決まります。手元の 3 つの場合で見ます。

範囲の中で直せるとき：npm audit fix で足りる

同じ minimist を、既定の ^ 付き（^1.2.5 は、次のメジャー版 2.0.0 より前の版、という範囲）で入れた場合です。

$ npm install minimist@1.2.5 --ignore-scripts    # 保存は既定の ^ 付き
…
  npm audit fix
…
$ grep -A2 '"dependencies"' package.json
  "dependencies": {
    "minimist": "^1.2.5"
  }
$ npm audit
# npm audit report

minimist  1.0.0 - 1.2.5
Severity: critical
Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h
fix available via `npm audit fix`
node_modules/minimist

1 critical severity vulnerability

To address all issues, run:
  npm audit fix
[exit 1]

fix available via の行が --force なしになり、--json の違いは fixAvailable が true になるだけでした。

$ npm audit fix --ignore-scripts

changed 1 package, and audited 2 packages in 478ms

found 0 vulnerabilities
[exit 0]
$ grep -A2 '"dependencies"' package.json
  "dependencies": {
    "minimist": "^1.2.5"
  }
$ npm ls --all
caret@1.0.0 <scratch>/vn/run/caret
`-- minimist@1.2.8

minimist は 1.2.8 に上がり、found 0 vulnerabilities になりました。package.json の ^1.2.5 はそのままで、変わったのは lock ファイルと node_modules です（<scratch> は作業フォルダーのパスの置き換えです）。告知が「直る」と書く 1.2.6 ではなく、範囲の中のもっと新しい 1.2.8 に上がるのは、npm の文書が「告知の無い版に上げる」と書くとおりです。

間接の依存と、meta-vulnerability

自分が入れていないパッケージが、脆弱な部品を連れてくる場合です。手元では、古い mkdirp@0.5.1 を入れました。これが minimist@0.0.8 を連れてきます。

$ npm install mkdirp@0.5.1 --ignore-scripts
…
$ npm ls --all
trans@1.0.0 <scratch>/vn/run/trans
`-- mkdirp@0.5.1
  `-- minimist@0.0.8

$ npm audit
# npm audit report

minimist  <=0.2.3
Severity: critical
Prototype Pollution in minimist - https://github.com/advisories/GHSA-vh95-rmgr-6w4m
Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h
fix available via `npm audit fix`
node_modules/minimist
  mkdirp  0.4.1 - 0.5.1
  Depends on vulnerable versions of minimist
  node_modules/mkdirp

2 critical severity vulnerabilities

To address all issues, run:
  npm audit fix
[exit 1]

報告は 2 つのパッケージ、minimist と mkdirp です。「2 critical severity vulnerabilities」の 2 は、告知の数ではなく、パッケージの数です。mkdirp 自身には告知がありませんが、critical と数えられました。これが meta-vulnerability で、npm の文書では、脆弱なパッケージの脆弱な版にしか依存できないせいで、自分には穴が無くても脆弱と数えられる依存を指します。

$ npm audit fix --ignore-scripts

changed 2 packages, and audited 3 packages in 683ms

found 0 vulnerabilities
[exit 0]
$ npm ls --all
trans@1.0.0 <scratch>/vn/run/trans
`-- mkdirp@0.5.6
  `-- minimist@1.2.8

mkdirp は 0.5.6、minimist は 1.2.8 に上がり、0 件になりました。--json では、minimist の isDirect が false で effects に mkdirp が入り、mkdirp の via は告知ではなく minimist という文字列でした。

範囲の外に出るときだけ：--force

3 つめは、1.2.5 と決め打ち（--save-exact）で書いた場合です。直す版（1.2.8）が、書いた範囲の外になります。

$ npm audit fix --ignore-scripts

up to date, audited 2 packages in 608ms

# npm audit report

minimist  1.0.0 - 1.2.5
Severity: critical
Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h
fix available via `npm audit fix --force`
Will install minimist@1.2.8, which is outside the stated dependency range
node_modules/minimist

1 critical severity vulnerability

To address all issues, run:
  npm audit fix --force
[exit 1]

npm audit fix は何も変えず、終了コード 1 で終わりました。--force を付けると、次のようになります（別のフォルダーに写してから流しました）。

$ npm audit fix --force --ignore-scripts
npm warn using --force Recommended protections disabled.
npm warn audit Updating minimist to 1.2.8, which is outside your stated dependency range.

changed 1 package, and audited 2 packages in 1s

found 0 vulnerabilities
[exit 0]
$ grep -A2 '"dependencies"' package.json
  "dependencies": {
    "minimist": "^1.2.8"
  }

--force は、package.json を書き換えました（1.2.5 が ^1.2.8 に）。npm の文書は、--force を「書いてある依存の範囲の外（SemVer のメジャーの変更を含む）に上げるのを許す」ものと説明し、「何をしたいか分かっていないなら、使わないことを強く勧める」と書いています。

SemVer（版の数字の付け方の決まり。メジャー.マイナー.パッチ）のメジャーが上がると、使い方が変わる変更が入っていることがあります。この例の 1.2.5 から 1.2.8 はメジャーの変更ではなく、isSemVerMajor も false でしたが、それでも --force が要りました。決め打ちで書いたため、範囲の外になったからです。「--force が要る＝メジャーが上がる」とは限らないので、実行の前に何が変わるかを確かめます。文書によると npm audit fix --dry-run --json で何をするかだけを見られます（流していません）。公開から日が浅い版を待つ設定（min-release-age）を使っていると、直った版を入れられず警告して 0 以外で終わることがあります（npm・yarn・pnpm の違い）。

fixAvailable の 3 つの形

手元で見た fixAvailable は 3 つの形でした。true は範囲の中で直る（npm audit fix で足りる）。{"name", "version", "isSemVerMajor": false} は --force が要る（メジャーの変更を意味しません）。false は直す手段が無い（No fix available。後の節の peer の例）。

npm audit が教えてくれないことは？

「0 件」は、安全という意味ではない

npm の文書は、「脆弱性が見つからなかった」は、知られた脆弱性のあるパッケージが、依存の木の中に見つからなかったという意味だと書いています。そのうえで、告知の一覧はいつでも増えるので、定期的に手で流すか、CI（変更のたびに自動でテストなどを流す仕組み）に入れるよう勧めています。

つまり、0 件は「いま一覧にある告知には当たらなかった」という結果で、「この先も大丈夫」とは言っていません。

全部の告知が出るわけではない

React と Next.js の脆弱性の記事で扱った 5 件の GHSA は、リポジトリで公開されたのが 2026-10-14 でした。2026年10月19日の時点で、5 件とも全体の Advisory Database に無く、npm audit にも出ませんでした（同じ時期の sharp の件は出ました）。2026年10月21日に gh api advisories/<GHSA> で引き直しても、5 件とも 404（無い）で、公開から 7 日たっても全体の一覧に入っていません。

$ for g in GHSA-xqc2-xf4c-x3h3 GHSA-h3gv-c5rc-p453 GHSA-673q-mjm6-r5xr GHSA-2464-fhr4-w9xw GHSA-p3m5-59mp-jv5r; do gh api advisories/$g; done
gh: Not Found (HTTP 404)    # 5 件とも同じ（{"message":"Not Found",…,"status":"404"}）

GitHub の文書も、新しい脆弱性が Advisory Database に入って通知になるまで、時間がかかることがある、と書いています。

告知そのものを引いてみる

GitHub の GHSA は、gh api（GitHub CLI。読むだけの操作です）でそのまま読めます。minimist の GHSA-xvch-5gv4-984h を引いて、要る欄だけ取り出しました。

$ gh api advisories/GHSA-xvch-5gv4-984h    # 要る欄だけ取り出した
ghsa_id : "GHSA-xvch-5gv4-984h"
cve_id : "CVE-2021-44906"
type : "reviewed"
severity : "critical"
summary : "Prototype Pollution in minimist"
published_at : "2022-03-18T00:01:09Z"
updated_at : "2024-06-21T21:33:52Z"
github_reviewed_at : "2022-03-18T23:13:40Z"
nvd_published_at : "2022-03-17T16:15:00Z"
cwes : [{"cwe_id": "CWE-1321", "name": "Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')"}]
epss : {"percentage": 0.04581, "percentile": 0.915}
cvss : {"vector_string": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "score": 9.8}
cvss_severities : {"cvss_v3": {"vector_string": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H", "score": 9.8}, "cvss_v4": {"vector_string": null, "score": 0.0}}
{'ecosystem': 'npm', 'name': 'minimist'} >= 1.0.0, < 1.2.6 1.2.6
{'ecosystem': 'npm', 'name': 'minimist'} < 0.2.4 0.2.4

読み方です。type が reviewed なので、Dependabot の通知の対象になる告知です。cvss_v4 は vector_string が null で、4.0 の点は付いていません（score が 0.0 でも「None」とは読みません）。当たる版は 2 つの範囲で、>= 1.0.0, < 1.2.6（1.2.6 で直る）と < 0.2.4（0.2.4 で直る）です。epss の欄の名前は percentage ですが、値は 0〜1 の確率で、FIRST の API の 0.045810000 と同じです。日ごとに変わるので、これは 2026-10-20 の値です。

peer の依存：文書と手元の結果が違う

npm の文書（「Auditing package dependencies for security vulnerabilities」）は、「npm audit は direct の依存・devDependencies・bundledDependencies・optionalDependencies を調べるが、peerDependencies は調べない」と書いています（peerDependencies は、ライブラリが「この部品は使う側が入れておいてほしい」と指定する依存です）。ただし同じページには「npm audit は npm@6 で使える」という古い書き方もあります。

手元の npm 11.19.0 では、違う結果になりました。中身が module.exports = 1; だけの peerlib という試験用のパッケージを手で作り、peerDependencies に minimist の 1.2.5 を書いて入れると、minimist が peer として入ります（lock ファイルでは "peer": true）。

$ cat peerlib/package.json
{ "name": "peerlib", "version": "1.0.0", "peerDependencies": { "minimist": "1.2.5" } }
$ (cd peerlib && npm pack)
peerlib-1.0.0.tgz
$ (cd peer && npm install ../peerlib/peerlib-1.0.0.tgz --ignore-scripts)
…
2 critical severity vulnerabilities

Some issues need review, and may require choosing
a different dependency.

Run `npm audit` for details.
$ npm ls --all
peer@1.0.0 <scratch>/vn/run/peer
`-- peerlib@1.0.0
  `-- minimist@1.2.5
$ npm audit
# npm audit report

minimist  1.0.0 - 1.2.5
Severity: critical
Prototype Pollution in minimist - https://github.com/advisories/GHSA-xvch-5gv4-984h
No fix available
node_modules/minimist
  peerlib  
  Depends on vulnerable versions of minimist
  node_modules/peerlib

2 critical severity vulnerabilities

Some issues need review, and may require choosing
a different dependency.
[exit 1]

peer として入った minimist も npm audit に出ました（No fix available。peer の指定が決め打ちだからです）。文書と手元の結果は食い違っているので、この記事はどちらが正しいとは決めず、両方を書きます。使っている npm の版で、自分で確かめてください。

devDependencies も、既定では出る

開発用の依存（devDependencies）も、既定では報告に出ます。手元では npm install -D minimist@1.2.5 のあと、npm audit は 1 件を報告し、終了コードは 1 でした。--omit=dev を付けると found 0 vulnerabilities（終了コード 0）になりました。

$ npm audit | tail -4
1 critical severity vulnerability

To address all issues, run:
  npm audit fix
[exit 1]
$ npm audit --omit=dev
found 0 vulnerabilities
[exit 0]

本番に入る部品だけを見たいのか、開発の道具も含めて見たいのかで、使い分けます。

lock ファイルが無いと、動かない

package-lock.json が無いと、npm audit は動きません。

$ npm audit
npm error code ENOLOCK
npm error audit This command requires an existing lockfile.
npm error audit Try creating one first with: npm i --package-lock-only
npm error audit Original error: loadVirtual requires existing shrinkwrap file
[exit 1]

手元のエラーの名前は ENOLOCK でしたが、npm の文書（「Resolving EAUDITNOPJSON and EAUDITNOLOCK errors」）は EAUDITNOLOCK と書いています。名前は違いますが、直し方（npm i --package-lock-only）は同じです。

試していないこと: npm audit がマルウェアの告知や unreviewed の告知を出すか（悪い版を取りに行かない方針）、--audit-level、--package-lock-only、yarn と pnpm の audit。

Dependabot alerts が教えてくれないことは？

Dependabot alerts は、GitHub のリポジトリの設定で有効にする機能です。GitHub Docs によると、既定のブランチを見て、新しい脆弱性が GitHub Advisory Database に足されたとき、または依存のグラフが変わったとき（パッケージや版を更新するコミットを push したときなど）に通知を出します。通知には、当たるファイルへのリンク、脆弱性と重さの詳細、直った版の情報（あれば）が載ります。

公式の Limitations（5 つ）

公式の制限	読み方
すべての問題を見つけられるわけではない。マニフェスト（依存を書いたファイル）と lock ファイルを最新に保つ	通知の正しさは、リポジトリのファイルが最新かどうかに左右される
新しい脆弱性が Advisory Database に入って、通知になるまで、時間がかかることがある	一覧に入る前は、通知もできない（前の節の React・Next.js の例）
GitHub が確かめた告知（reviewed）だけが、通知になる	unreviewed は通知されない
アーカイブしたリポジトリは見ない	アーカイブしたリポジトリは、通知が来ない
GitHub Actions は、セマンティックバージョンの指定だけ。SHA の指定は、通知が出ない	下の説明

最後の制限は、GitHub Actions の使い方の SHA の固定と関わります。Dependabot は、v4 のようなセマンティックバージョンで指定した action には脆弱性の通知を作りますが、SHA の値で固定した action には作りません。つまり、SHA で固定した action に脆弱性があっても、Dependabot の通知は来ません。

有効にした直後は、既存の脆弱性のお知らせ（メール）を全部は送らない

GitHub Docs の「How alert notifications work」によると、Dependabot を有効にした最初の時点では、すでにある脆弱な依存のすべてについてはお知らせ（メールなどの notification）を送りません。お知らせが届くのは、有効にしたあとに見つかった新しい脆弱な依存についてです（お知らせの設定が許せば）。マルウェアの通知も、有効にしたときだけ作られます。

この記事では、Dependabot alerts を動かしていません。リポジトリの設定を変える操作なので、通知の画面や文面は確かめていません。書いたのは、GitHub Docs を2026年10月21日に開いて読んだ内容です。

よくある質問

npm audit が 0 件なら、安全ですか？

npm の文書によると、0 件は「知られた脆弱性のあるパッケージが、依存の木の中に見つからなかった」という意味で、告知の一覧はいつでも増えると書いています。手元では、2026年10月14日に公開された React と Next.js の 5 件の告知が、10月19日の npm audit に出ませんでした。

npm audit fix --force を付けて直してよいですか？

npm の文書は、何をしたいか分かっていないなら使わないよう、強く勧めています。手元では、1.2.5 と決め打ちしたときに、メジャーの変更ではないのに --force が要り、package.json が書き換わりました。付ける前に、何が変わるかを見ます。

自分のアプリで確かめること（チェックリスト）

脆弱性の点を見るとき、それが CVSS-B（Base だけ）かを確かめ、深刻度とリスクを混ぜていないか（→「CVSS-B は深刻度で、リスクではない」）
同じ脆弱性の点が NVD と GitHub で違うとき、どこが、どの版で付けた点かを見ているか（→「同じ脆弱性なのに点が違うのはなぜ？」）
悪用の有無を KEV で確かめているか。KEV に無いことを「悪用されていない」と読んでいないか。EPSS と CVSS を掛けていないか（→「KEV とは？ EPSS との違いと、CVSS と掛けてはいけない理由」）
npm audit を CI などで定期的に流しているか。「0 件」を「安全」と読んでいないか（→「「0 件」は、安全という意味ではない」）
公開直後の知らせは、npm audit や Dependabot にまだ出ないことがあると知っているか（→「全部の告知が出るわけではない」）
package-lock.json を置いているか。本番に入る部品だけを見るか、開発用も含めるか決めているか（→「lock ファイルが無いと、動かない」）
npm audit fix --force の前に、package.json の何が変わるかを見ているか（→「範囲の外に出るときだけ：--force」）
Dependabot の制限（確かめた告知だけ・SHA 指定の action は通知が出ない・有効にした直後は既存の分のお知らせ（メール）を全部は送らない）を知っているか（→「公式の Limitations（5 つ）」）

まとめ

CVE は脆弱性に番号を付ける仕組み（CNA が自分の範囲で割り当てる）。NVD は別の仕組みで、CVE に情報を足す。CVSS は CVE が無くても使える
CVSS-B（Base だけの点）は深刻度で、リスクではない。単独でパッチの順番を決めない。出す人で点は違うので、どこが、どの版で付けたかを見る
KEV は、悪用が確認された脆弱性の一覧。載る条件は、CVE ID・確かな悪用の証拠・直し方の 3 つ。EPSS はこの先 30 日の予測で別の問い。EPSS と CVSS は掛けない
npm audit の「0 件」は、知られた脆弱性のあるパッケージが木に無かった、という意味。--force は範囲の外に上げて package.json を書き換え、メジャーの変更とは限らない。情報源は「GitHub Advisory Database を見ている」と言い切らない
Dependabot は、GitHub が確かめた告知（reviewed）だけを通知する。時間差・アーカイブは見ない・SHA 指定の action は通知が出ない、などの制限がある
手元の確かめは macOS 14.4.1・Node.js 24.21.0・npm 11.19.0 の結果。文書と食い違うもの（peer の扱いなど）は両方書いた。Dependabot は動かしていない