{{ summaryHeading }} {{ summaryPrimary }} {{ summaryLine }} {{ badge.label }} {{ badge.value }}
JSON exposes package paths and fix availability; terminal text can still produce a gate and severity summary.
{{ sourceStatus }}
Auto detect resolves to JSON only after a successful JSON parse; otherwise it uses the terminal-report parser.
Use a label that will still make sense in a remediation ticket or exported report.
Use 1 when any critical or high vulnerability should fail the local gate.
high+
The default shows up to 200 prioritized rows. Totals use all findings; the machine summary records any detail truncation.
rows

Release decision

{{ decisionHeading }}
{{ decisionSummary }}
  1. {{ item }}
MeasureValueInterpretationCopy
{{ row.label }}{{ row.value }}{{ row.context }}
PackageSeverityDependencyFix pathEvidence pathNext actionCopy
{{ row.package_name }}{{ row.severity.charAt(0).toUpperCase() + row.severity.slice(1) }}{{ row.dependency }}{{ row.fix_signal }}{{ row.evidence_path }}{{ row.action }}
No package-level findings were present. Use npm audit --json when ownership and paths matter.

Remediation queue

Highest severity and most disruptive fix paths appear first.

{{ chartError }}

Correct the audit input to view the chart.

CI Failure Log Analyzer Find actionable clues in a failed CI log, map them to pipeline stages, and mask common secret patterns before sharing the evidence.
JUnit Test Report Analyzer Analyze JUnit XML locally for pass rates and release gates with focused triage for failures, retries, skipped cases and slow tests.
SARIF Security Findings Analyzer Analyze SARIF logs into a local release gate with prioritized findings plus hotspot and tracking-coverage checks for security review.
Container Security Scan Analyzer Normalize container scan reports, apply critical and high release limits, and rank fixable findings for a focused remediation queue.

An npm audit report connects a resolved dependency tree with vulnerability advisories known to the configured registry. It can expose risk in a package named directly by a project or in a transitive package pulled in several levels below it. The useful question is therefore not only how many findings exist, but which package paths are affected and what kind of change would remove them.

Release decisions usually combine several facts. Severity describes the advisory signal, while runtime reachability, deployment context, package ownership, and available remediation determine urgency. One critical issue on an exposed production path can matter more than many low-severity findings in development-only code. A passing count threshold is still not evidence that an application has no vulnerabilities.

Direct dependency
A package declared by the project itself.
Transitive dependency
A package installed because another dependency requires it.
Compatible fix
An update that stays within the dependency range accepted by the project.
Major or forced fix
A change that may cross declared version ranges and needs regression review.

A release gate turns policy into a repeatable decision, but it should remain local to the project. Teams may block any critical or high finding, allow a documented exception, or distinguish production from development paths. The threshold does not replace advisory review, and a proposed automatic fix does not prove that the upgraded application still behaves correctly.

Audit coverage also has a boundary. Results depend on the dependency tree submitted by npm, the registry and advisories available at that time, and any included or omitted dependency types. Unknown vulnerabilities, private application flaws, malicious behavior without an advisory, and unreachable code paths require other evidence.

How to Use This Tool:

Start with the most structured audit output available, then set the project-specific count that should stop a release.

  1. Paste or load npm audit --json output when package paths and fix availability matter. A copied terminal report can still produce severity totals and a gate.
  2. Leave Input format on Auto detect for ordinary reports. Select npm audit JSON when malformed JSON must be rejected rather than interpreted as terminal text.
  3. Enter a Project label that identifies the branch, workspace, or CI run without changing the analysis.
  4. Set High+ fail threshold to the smallest critical-plus-high count that should fail local policy. A value of 1 fails on the first critical or high finding.
  5. Read Release decision first, then use the remediation queue to distinguish compatible updates, breaking-change review, and packages with no direct fix.

Interpreting Results:

The gate fails when the critical-plus-high count is greater than or equal to the selected threshold. A pass means only that this local count rule was not met. Review moderate and low findings, package reachability, and any aggregate-only evidence before approving a release.

  • Pressure points make severity mixes easier to compare across repeated audits of the same project; they are not an npm or industry risk score.
  • Remediation queue rows are ordered by severity, then fix pressure, then package name. A visible-row limit can shorten that queue without changing totals or the gate.
  • An aggregate-only report can support a count gate but cannot identify package ownership or the exact dependency path. Rerun the audit in JSON form when those details affect the decision.

Technical Details:

Modern npm audit JSON may provide aggregate severity counts together with package records, dependency paths, vulnerable ranges, advisory details, and fix availability. Older advisory-shaped JSON is also recognized. Terminal text is parsed more conservatively, so a copied excerpt may retain counts while losing package-level evidence.

Formula Core:

The local gate uses one count rule, while the pressure index weights higher-severity findings more heavily.

Nhigh+ = Ncritical+Nhigh gate fails = Nhigh+≥T P = 10Ncritical+6Nhigh+3Nmoderate+Nlow

Here, T is the selected high-plus threshold and P is the integer pressure-point total. Informational findings carry zero points. Counts are retained as whole numbers, and no display rounding changes the gate.

Rule Core:

Evidence Classification Practical meaning
No fix available or manual-review wording Manual remediation Assess replacement, override, exposure, or upstream status.
SemVer-major, breaking, or force-update signal Force/major review Test the change in an isolated branch before release.
Update is listed without a breaking signal Compatible fix Apply the update, rerun the audit, and run package tests.
No usable fix signal Advisory review Open the advisory and confirm that the affected path is relevant.

Package rows are sorted critical before high, moderate, low, and informational findings. Within a severity, manual work precedes major review, compatible fixes, and advisory-only review. JSON aggregate counts remain authoritative when present; package rows are used to derive counts only when aggregate vulnerability counts are absent.

A report with one critical, two high, three moderate, and one low finding has a high-plus count of 3. With a threshold of 1, the gate fails. The pressure index is 32 points: 10 + 12 + 9 + 1. This substitution is useful for checking the calculation, but the package paths and fix classifications still decide the work.

The source is bounded to 500,000 characters and at most 200 package findings are retained. The visible queue can show 5 to 200 rows. These limits do not turn a partial terminal excerpt into complete audit evidence.

Privacy and Accuracy Notes:

Audit text and loaded files are parsed in the current browser and are not uploaded for analysis.

  • Keep the original audit report when exact advisory text, registry output, or an audit trail is required.
  • Review dependency paths and runtime exposure before treating severity as exploitability.
  • Test all remediation changes. A compatible label describes version-range fit, not application compatibility.

References: