I ran npm audit and DepGra on the same project — here's what each one caught

Source: Dev.to

npm audit

npm audit reported 10 vulnerabilities (3 moderate, 7 high) across 8 packages:

npm audit also indicates whether fixes are available and if they would require breaking changes—information that DepGra does not provide.

DepGra scan

DepGra scanned the same package-lock.json in 6.5 seconds, finding 12 unique advisories across 10 packages:

All 11 advisories reported by npm audit appear in DepGra’s results, plus one extra advisory:

• GHSA-5f7q-jpqc-wp7h (CVE‑2025‑59472) – Next.js unbounded memory consumption via PPR resume endpoint (published 2026‑01‑28). This advisory is present in OSV.dev (DepGra’s source) but not yet in the GitHub Advisory Database used by npm audit.

Why the difference?

• Data sources: DepGra queries OSV.dev, which aggregates multiple vulnerability feeds. npm audit queries the GitHub Advisory Database. Timing differences between these sources can cause discrepancies.
• Severity scoring: npm audit classifies serialize-javascript as high, while DepGra pulls the full CVSS vector and rates it critical.
• Counting methodology: npm audit counts each vulnerable package instance; DepGra counts unique CVE IDs.

Graph insights

When loading the DepGra scan into its graph view, two patterns become apparent:

1. Minimatch as a chokepoint
   The flat list shows three high‑severity advisories for minimatch. The graph reveals that minimatch@3.1.2 is a transitive dependency of several widely used packages (@sentry/node, @typescript-eslint/typescript-estree, glob). Its blast radius is therefore larger than severity alone suggests.

2. Multiple risk paths to serialize-javascript
   The flat list lists a single line item, but the graph shows two distinct dependency chains:

   • copy-webpack-plugin → serialize-javascript@6.0.2
   • terser-webpack-plugin → serialize-javascript@6.0.2

   Both paths lead to a critical RCE vulnerability, highlighting the benefit of visualizing topology rather than relying on manual npm ls analysis.

Technical stack

• Parsers: package-lock.json, Cargo.lock, poetry.lock, requirements.txt, go.mod
• Vulnerability source: OSV.dev batch API (single request for all packages, followed by detailed fetches)
• Storage & analysis: SQLite + NetworkX (centrality scoring, path finding)
• API: Flask (REST)
• Frontend: Svelte + Cytoscape.js (graph rendering)
• Layout algorithm: Topological sort for DAG layout – O(V + E), handling > 1,300 nodes efficiently
• Python requirements.txt handling: Resolves transitive dependencies via the PyPI API (since lockfiles are not available)

Installation & usage

# Clone the repository
git clone https://github.com/KPCOFGS/depgra
cd depgra

# Backend setup
cd backend
uv venv .venv
source .venv/bin/activate
uv pip install -r requirements.txt
cd ..

# Frontend setup
cd frontend
npm install
npm run build
cd ..

# Run the server
python run.py
# Open http://127.0.0.1:5000

CLI alternative

# Scan a lockfile
python run.py scan path/to/package-lock.json

# Scan a requirements file and fail on HIGH severity or above
python run.py scan requirements.txt --fail-on HIGH

Limitations

• No auto‑remediation: DepGra does not suggest version upgrades or create fix pull requests (unlike npm audit fix).
• Scope: Focused solely on dependency‑vulnerability visualization—no container scanning, license compliance, or secrets detection.
• Severity variance: Classifications come from OSV.dev and may differ from those reported by other tools (e.g., Snyk, npm audit).
• Large graphs: Visualizations for > 1,000 packages become dense; still functional but less tidy than smaller graphs.

Future directions

• SBOM export (CycloneDX / SPDX)
• Automated remediation suggestions (minimum version upgrades that resolve CVEs)
• GitHub Action for CI/CD integration

The project is MIT‑licensed and welcomes feedback.