npm Audit Summary Analyzer

Introduction

npm audit output is a dependency-security snapshot. It reports vulnerabilities found in the packages that make up a JavaScript project, then groups those findings by severity and remediation signal. That makes the summary useful before a release, after a continuous integration failure, or during routine dependency maintenance when the raw report is too long to scan quickly.

The most urgent question is usually whether the project contains critical or high vulnerabilities. A single severe finding can be enough to block a build in many teams, but the raw audit output can mix direct dependencies, transitive paths, advisory text, and aggregate counts. A readable summary separates the release gate from the remediation queue so a reviewer can decide whether to patch, plan a major update, or investigate a dependency path first.

Severity counts are not a complete risk assessment. An unreachable development-only path may be less urgent than a production-facing direct dependency, and a major-version fix can require testing before it is safe to apply. The useful reading is a triage reading: identify the most serious audit signal, confirm the package path, and keep enough evidence for the owner who must fix or accept the finding.

The output should not be treated as proof that a project is secure. npm audit depends on the advisory data available to npm and the dependency graph in the audited install. A clean result means no matching vulnerabilities were reported for that audit run, not that the application has no security defects.

Technical Details:

npm audit compares a package tree with npm advisory data and reports matching vulnerabilities by severity. Modern JSON reports can include aggregate severity counts, dependency totals, package-level vulnerability objects, package paths, affected version ranges, advisory titles, and fix availability. Older report shapes may expose advisories in a different object, and terminal text may contain only counts and a few lines of package context.

Severity names use the familiar npm scale: critical, high, moderate, low, and info. The analyzer normalizes medium to moderate for pasted text, then sorts the most severe items first. When JSON includes package-level rows, each finding can also carry whether it is direct, which dependency paths are involved, and whether npm sees an automatic, breaking, manual, or uncertain remediation path.

The release gate is based on the high-plus count. High-plus means critical vulnerabilities plus high vulnerabilities. The gate fails when that count is greater than or equal to the selected threshold, so a threshold of 1 means any critical or high issue fails the gate.

Fix pressure is derived from the audit report's fix signal. A plain available fix is treated as compatible. A fix that needs npm audit fix --force, a semver-major change, or a breaking-change review is treated as major. A finding with no direct fix becomes manual remediation. Findings without enough fix detail stay in advisory review. If the pasted source exposes only aggregate counts, the pressure view marks the result as aggregate-only because package rows are not available.

The parser accepts two source families. JSON is preferred because it can expose dependency totals, package paths, fix availability, affected ranges, and package-level advisories. Text reports are useful for copied terminal output, but they can lose detail. The text parser looks for severity count lines, package headings, Severity: labels, node_modules paths, advisory URLs, and fix-available wording. If a text report does not contain recognizable audit markers, the page asks for npm audit JSON or terminal report text instead of producing a false summary.

Everyday Use & Decision Guide:

Start with npm audit --json when you can. JSON gives the analyzer package names, paths, fix availability, dependency totals, and advisory detail that copied terminal text may omit. Use text input when you only have a CI log or terminal paste and need a quick count-based summary.

Set Project label to the package, workspace, branch, or CI job the audit came from. The label appears in the summary and copied rows, so use wording that will still make sense after the result is pasted into a ticket. Leave Parser preference on Auto-detect for normal use. Choose JSON first when malformed JSON should stop the run, and choose Text report when a pasted log should be read as terminal output even if it contains JSON-like fragments.

• Use High+ fail threshold to match the release policy. A value of 1 fails on any critical or high vulnerability.
• Use Remediation rows to control how many package rows appear in Package Remediation Queue. The accepted range is 5 to 100, with 25 as the default.
• Use Format JSON only after pasting valid JSON. If the source is terminal text, the page keeps the text and shows a JSON-format warning instead.
• Use Severity Mix Chart to show how the audit count is distributed, and Fix Pressure Chart to show how much of the package queue is compatible, major, manual, or review work.

The strongest first-pass signal is the summary box. If it shows npm Audit Gate Failing, the high-plus count met or exceeded the selected threshold. If it shows npm Audit Gate Passing, critical and high counts are below that threshold, but moderate and low findings may still need scheduled dependency work.

Do not treat a compatible fix as safe without checks. Even a non-major dependency update can change behavior, especially in build tools and transitive dependency chains. Apply the update, rerun npm audit, and run the relevant package tests before using the result as release evidence.

Step-by-Step Guide:

Run the summary from one audit source so the gate result, tables, charts, and JSON snapshot all describe the same dependency state.

1. Enter a clear Project label, such as a workspace name, branch, or CI job. The summary row should show that label instead of Unlabeled.
2. Set High+ fail threshold. Use 1 for a zero-critical-or-high release gate, or a higher number when your policy allows a limited high-plus count.
3. Paste npm audit --json output into Audit output, drag in a JSON or text report, or use Browse audit. The source status line should show the character count and whether the parser read JSON or text.
4. Leave Parser preference on Auto-detect unless the run needs stricter handling. If The source is not valid JSON. appears, either fix the JSON or switch to text parsing when the source is terminal output.
5. Read the summary. A valid run shows the high-plus count, total vulnerabilities, pressure points, and visible queue rows. If Audit Input Needs Review appears, clear the validation message before exporting.
6. Open npm Gate Snapshot and Severity Ledger to confirm the release decision and the severity mix. Check Fix Pressure Matrix before deciding whether the next action is a compatible update, major review, manual remediation, or advisory review.
7. Use Package Remediation Queue for owner handoff. Copy the most important rows only after package names, dependency type, fix signal, paths, and action text match the audit source.
8. Use the chart and JSON tabs only after the tables look coherent. The charts summarize severity and fix pressure, while the JSON tab keeps the normalized snapshot for automation notes or ticket attachments.

A clean finish is a gate result that matches policy, a queue whose top rows are explainable, and a rerun plan after fixes are applied.

Interpreting Results:

Read the gate result before the total vulnerability count. Ten low findings may be routine maintenance, while one critical finding can block a release. The high-plus count and selected threshold explain the pass or fail state more clearly than the total count alone.

• Fail in npm Gate Snapshot means critical plus high findings are greater than or equal to High+ fail threshold. Treat this as a release-policy stop until the owner accepts or fixes the issue.
• Pass means the high-plus count is below the threshold. It does not mean the dependency tree is healthy or that moderate findings are irrelevant.
• Pressure points are a rough weighted index. Use them to compare two runs of the same project, not as a universal security score.
• Aggregate only means the pasted source did not expose package rows. Paste JSON when you need package names, paths, and fix signals.
• Manual remediation deserves attention even when severity is not critical. No direct fix often means the owner must inspect replacement packages, overrides, or upstream progress.

The best verification cue is a second audit after changes. If the queue says Compatible fix, apply the package update and rerun npm audit plus tests. If the queue says Force/major review, verify the breaking-change branch before treating the count drop as a safe fix.

Worked Examples:

Release gate fails on one severe package

A CI job for admin-ui main branch pastes JSON with 1 critical, 0 high, 3 moderate, and 1 low vulnerability. With High+ fail threshold set to 1, npm Gate Snapshot shows Fail because the high-plus count is 1. The owner should open Package Remediation Queue, confirm whether the critical package is direct or transitive, then work from the shown fix signal.

A major fix needs a test branch

An audit row for webpack-dev-server reports a critical issue and a fix that requires a semver-major update. The queue places it near the top because severity is high pressure, and Fix Pressure Matrix groups it under Force/major review. The useful result is not simply that a fix exists; it is that the fix should be tested in a breaking-change branch before release evidence is accepted.

Copied text gives only aggregate counts

A terminal log says found 7 vulnerabilities (1 low, 3 moderate, 2 high, 1 critical) but does not include package rows. The gate and severity ledger can still summarize the count, but Fix Pressure Matrix may show Aggregate only and Package Remediation Queue may be empty. The corrective path is to rerun npm audit --json and paste that output when package-level planning is required.

Invalid JSON is not silently reinterpreted

A saved report is missing a closing brace and Parser preference is set to JSON first. The page shows The source is not valid JSON. and the summary asks for review instead of inventing a result. Fix the JSON, or switch to Text report only when the source is a terminal report rather than structured audit data.

FAQ:

Glossary:

npm audit

The npm command that checks an installed dependency tree against npm advisory data.

High-plus

The combined count of critical and high vulnerabilities used for the release gate.

Fix pressure

The remediation grouping that separates compatible fixes, major or force fixes, manual work, and advisory review.

Direct dependency

A package listed directly by the project rather than pulled in through another package.

Transitive dependency

A package installed because another dependency requires it.

Semver-major

A version change that can include breaking changes under semantic versioning rules.

References:

• npm-audit, npm Docs.
• About audit reports, npm Docs, January 14, 2026.
• About semantic versioning, npm Docs, January 14, 2026.