npm Audit Summary Analyzer

Introduction:

An npm audit report is a snapshot of known dependency risk in one package tree. It compares the dependencies described by a project and its lockfile against vulnerability advisories known to the configured registry. That makes it useful for release checks and maintenance planning, but it is still evidence to review rather than a final statement that an application is safe or unsafe.

Large JavaScript projects can carry many indirect packages, so the count alone rarely tells the whole story. The same report may include one direct production package, several transitive development packages, and a suggested fix that either stays inside the current version range or crosses into a breaking upgrade. Security owners usually need severity, package path, affected range, and fix pressure before deciding whether to block a release, open a patch branch, or record a time-boxed exception.

Severity is a starting signal about impact and likelihood, not the release decision by itself. A single critical finding on a reachable production dependency can justify stopping a deployment. A high finding in a development-only transitive path may need a different response. The dependency path, package role, runtime exposure, and whether the fix is compatible all change the practical decision.

Severity

The advisory label, usually critical, high, moderate, low, or informational.

Dependency path

The route through the installed package tree that brings the vulnerable package into the project.

Patched range

The version range where the advisory says the vulnerability has been fixed.

Release gate

A policy threshold that decides whether a build can proceed with unresolved findings.

One common mistake is treating the total vulnerability count as the release decision. Ten low findings can be less urgent than one critical package on a production path. Another mistake is running npm audit fix --force as if every suggested fix were harmless. A forced or semver-major change can update top-level dependencies outside their current accepted ranges, so it belongs in a tested branch rather than an automatic release patch.

The report boundary matters. An audit can miss unknown vulnerabilities, malicious behavior that has not been published as an advisory, mistakes in private code, and risks hidden by omit/include settings. It should be read alongside reachability, ownership, test coverage, and the side effects of any proposed package update.

How to Use This Tool:

Use the analyzer when you have an npm audit JSON report, a copied terminal report, or a CI log excerpt and need a compact release or remediation summary.

1. Enter a Project label that will still make sense in an exported ticket, such as a package name, workspace, branch, or CI job.
2. Set High+ fail threshold. Use 1 when any critical or high vulnerability should fail the gate.
3. Paste npm audit --json when possible, browse to a saved JSON, TXT, or LOG report, or drop the file onto the audit textarea.
4. Leave Parser preference on Auto-detect for ordinary use. Choose JSON first when malformed JSON should stop the run instead of being treated as text.
5. Open Advanced only when you need to change the visible Remediation rows limit. The limit trims the visible queue, not the severity totals.
6. Read npm Gate Snapshot first, then use Severity Ledger, Fix Pressure Matrix, and Package Remediation Queue to decide who needs to patch, review, or investigate.
7. Use the chart tabs and exports after the tables match the report you meant to summarize.

If the page reports that the audit input needs review, fix the source before exporting. Text logs can be enough for a gate and severity ledger, but JSON usually gives better package names, dependency paths, affected ranges, dependency totals, and fix signals.

Interpreting Results:

Start with the high-plus count, which is the critical count plus the high count. The selected threshold turns that count into a pass or fail result for the gate. The gate is intentionally narrower than the full vulnerability total because critical and high findings often carry release-blocking weight even when lower severities are present.

The pressure score is a triage index, not a standard risk score. It makes repeated runs of the same project easier to compare by weighting critical findings more heavily than high, moderate, low, or informational findings. Use it to explain relative cleanup pressure, not to compare unrelated applications without context.

The JSON tab contains the normalized summary built by the page. Keep the original npm audit report when you need full advisory text, exact registry output, or evidence for an audit trail.

Technical Details:

npm audit builds a report from dependency metadata, known advisories, and remediation logic. Modern npm output may include aggregate vulnerability counts, dependency totals, affected packages, dependency paths, advisory references, vulnerable ranges, and fix guidance. A command-line text report often preserves the release signal, while JSON output is better for package ownership and remediation planning.

The analyzer uses the high-plus count as a local gate because critical and high findings often drive release policy. It also creates pressure points so a run with one critical advisory does not look equivalent to a run with one low advisory. These are triage measures for comparing audit runs and explaining cleanup pressure; they are not npm standard risk scores.

Formula Core:

npm Gate Snapshot records the project label, detected source type, gate result, high-plus count, total vulnerabilities, pressure score, dependency total when present, and queue size. Severity Ledger groups count, share, points, and recommended posture by severity. Fix Pressure Matrix groups package rows by remediation type. Package Remediation Queue keeps the sorted package details for handoff.

The tool's gate is separate from the npm CLI --audit-level option. The CLI option changes the command exit threshold; it does not remove lower-severity findings from the report. This page keeps the parsed counts visible and lets you choose a high-plus release threshold for the summary.

Privacy and Accuracy Notes:

The page analyzes pasted text and selected report files in the browser. It does not need to send the audit report away to build the tables, charts, CSV files, DOCX files, or JSON summary.

The npm command that produced the report is separate from this page. When you run npm audit in your terminal or CI job, npm may contact the configured registry and use the dependency tree described by your package lock. Private package names, internal project labels, and advisory paths can appear in reports and exports, so treat them as security artifacts.

Audit results can change when the lockfile, registry, npm version, advisory data, or omit/include settings change. A clean run means no known matching vulnerabilities were reported for that run; it does not rule out unknown vulnerabilities, malicious packages that have not been flagged, or risks in application code.

Worked Examples:

One critical finding fails a strict gate

A CI job for admin-ui main reports 1 critical, 0 high, 3 moderate, and 1 low vulnerability. With High+ fail threshold set to 1, the high-plus count is 1, so the gate fails. The owner should inspect the top queue row before deciding whether to patch immediately or record a release exception.

A major fix needs a review branch

A package row says a fix exists, but the fix requires a semver-major change. The row belongs under Force/major review, even when the severity is critical. The useful action is a tested upgrade branch, not a rushed force update that breaks the application.

A copied CI log gives only counts

A terminal excerpt says found 7 vulnerabilities with a severity breakdown but no package rows. The gate and severity ledger can still work, while the package queue may be empty or aggregate-only. Rerun npm audit --json when package ownership or dependency paths matter.

Invalid JSON stops a JSON-first run

A saved report is missing a closing brace and Parser preference is set to JSON first. The page reports invalid JSON instead of silently treating the source as text. Fix the JSON, or switch to text parsing only when the source is a terminal report.

FAQ:

Glossary:

High-plus

Critical vulnerabilities plus high vulnerabilities, used by this page as the release-gate count.

Pressure points

A weighted severity index used for triage, with critical findings contributing more than high, moderate, low, or informational findings.

Compatible fix

A remediation signal that is not marked as semver-major or force-only in the parsed audit data.

Manual remediation

A finding where the audit source does not expose a direct automatic fix path.

Aggregate-only result

A summary built from severity counts without package-level remediation rows.

References:

• About audit reports, npm Docs.
• npm-audit command documentation, npm CLI documentation.
• About semantic versioning, npm Docs.