TechLatest

Posted on Jun 1 • Originally published at Medium on May 25

CVE Lite CLI: The Dependency Scanner That Actually Tells You What to Run (Not Just What’s Broken)

#opensource #owasp #typescript #javascript

Last week, I was 20 minutes from pushing a hotfix. CI passed. Tests green. Then Dependabot pinged: “12 vulnerabilities found.”

I clicked through. Got a list of CVE IDs. No fix commands. No “upgrade this, not that.” Just a wall of red and a vague sense of dread.

I spent the next hour:

Googling each CVE
Checking if it was direct or transitive
Figuring out which parent package to bump
Testing if the upgrade broke anything
Finally, writing the right npm install command

By the time I pushed, the “quick fix” wasn’t quick at all.

If you’ve shipped JavaScript or TypeScript, you know this feeling. The gap between “something’s vulnerable” and “here’s exactly what to run to fix it” is where good intentions go to die.

That’s the exact problem CVE Lite CLI tries to solve.

It’s not another dashboard. Not another CI gate that blocks your PR at 2 AM. It’s a lightweight, local-first CLI that reads your lockfile, checks for known vulnerabilities, and spits out copy-and-run fix commands.

No account. No config. No source code leaves your machine.

I installed it yesterday. Scanned a few real projects. Here’s what actually happened — and whether it’s worth adding to your workflow.

First Things First: What Is This Thing, Really?

CVE Lite CLI is an OWASP Incubator Project — peer-reviewed by the same org behind the OWASP Top 10 — that scans your package-lock.json, pnpm-lock.yaml, yarn.lock, or bun.lock for known vulnerabilities.

But here’s the twist: instead of dumping a list of CVE IDs and calling it a day, it gives you:

✅ Copy-and-run fix commands — npm install @, pnpm add @, etc.

✅ Direct vs. transitive visibility — shows if the vuln is in something you installed or buried three levels deep

✅ Parent-aware remediation — for transitive deps, it tells you whether npm update Is enough, or if you need to bump the parent itself

✅ Offline mode — sync the advisory DB once, scan forever with zero network calls

✅ Usage-aware filtering — optionally check if vulnerable packages are actually imported in your code (cuts noise fast)

It’s built for the moment right before you push: fast, honest, and actionable.

Why This Feels Different (The Philosophy)

Most security tooling is designed for pipelines, not people.

Dependabot files PRs you’ll merge eventually. CI scanners block builds hours after you’ve context-switched. Dashboards surface CVE IDs with no clear path to resolution.

By the time you see a finding, the code is already reviewed, the momentum is gone, and you’re just trying to unblock the merge.

CVE Lite CLI flips that. It assumes:

“The best time to fix a vulnerable dependency is when you’re already in the terminal, about to push — not after CI fails.”

So it runs locally. It’s fast. It gives you the exact command to run. And it gets out of your way.

That’s not flashy. But it’s how real developers work.

Step 1: Installing CVE Lite CLI

Getting started takes less than a minute. No accounts, no cloud onboarding, no configuration files.

# Create a working directory
mkdir cve-lite-blog-test
cd cve-lite-blog-test

# Verify local environment
npm -v
# 10.8.2

node -v
# v20.20.2

# Install globally
npm install -g cve-lite-cli

The install pulls in ~43 packages and completes in ~16 seconds on a standard connection. A deprecation warning prebuild-install may appear—this is a transitive dependency notice and doesn’t block functionality. npm may also surface a version update prompt; neither requires action to run the scanner.

Step 2: Preparing a Controlled Test Environment

To evaluate CVE Lite CLI against a known baseline, we scaffolded a minimal Node.js project and intentionally installed dependency versions with documented vulnerabilities.

# Initialize a default package.json
npm init -y

# Install known vulnerable versions for testing
npm install lodash@4.17.20 express@4.17.1

npm init -y generates a standard package.json with default fields. The subsequent install pulls in lodash@4.17.20 and express@4.17.1, along with their transitive dependencies.

npm’s built-in audit immediately flags the risk:

Added 51 packages, and audited 52 packages in 2s

8 vulnerabilities (3 low, 5 high)

To address all issues, run:

npm audit fix

This output is familiar to any JavaScript developer. It confirms vulnerabilities exist and suggests a bulk fix command. However, it doesn’t clarify which vulnerabilities are direct vs. transitive, whether it npm audit fix will introduce breaking changes, or which parent packages actually need updating.

This is where CVE Lite CLI’s workflow diverges. Instead of a generic fix suggestion, it parses the same lockfile and returns a structured remediation plan with package-manager-aware commands, dependency path context, and severity prioritization.

Step 3: Running the First Scan (And Dealing With Unexpected Results)

With the test project ready, we ran the initial CVE Lite CLI scan:

cve-lite .

The output was immediate:

CVE Lite CLI (1.17.3)
✓ Scan dependencies
✓ Highlight critical issues
✓ Show a clear fix plan

Fast. Local. Developer-first.

Advisory source: OSV (https://api.osv.dev)
Parsed 69 packages from package-lock (package-lock.json)
✓ Queried OSV in 1 batch
✓ Scan complete. No known vulnerabilities found.

npm audit just reported 8 vulnerabilities, but CVE Lite found none.

This isn’t a bug. It’s a feature of how different vulnerability databases work:

npm audit checks against the npm security advisory database, which includes npm-specific metadata and sometimes broader matching rules
CVE Lite CLI queries the OSV (Open Source Vulnerabilities) database, which is a curated, cross-ecosystem standard

The discrepancy likely means:

npm’s database has broader matching (e.g., flagging version ranges rather than exact versions)
Some npm advisories haven’t been mirrored to OSV yet
npm may have already applied silent fixes during install

To verify what’s actually installed:

npm list lodash express

This shows the exact resolved versions in the dependency tree. If npm auto-fixed during install, the vulnerable versions might already be gone.

Step 4: Forcing the Vulnerable Baseline (Why npm “Helped” Too Much)

The npm list output confirms what happened:

express@4.22.2
lodash@4.18.1

Instead of installing express@4.17.1 and lodash@4.17.20, NPM's semver resolver automatically upgraded both packages to the latest patch versions within their major ranges. This is npm's default behavior when newer, non-vulnerable releases exist, and it's exactly what you want in production.

For testing purposes, however, it means our dependency tree is already clean. To demonstrate CVE Lite CLI’s remediation workflow, we need to pin the exact vulnerable versions and prevent automatic resolution.

# Remove existing modules and lockfile to start fresh
rm -rf node_modules package-lock.json

# Force exact vulnerable versions in package.json
npm install lodash@4.17.20 express@4.17.1 --save-exact

# Verify the resolved versions
npm list lodash express

Expected output:

cve-lite-blog-test@1.0.0 /path/to/project
├── express@4.17.1
└── lodash@4.17.20

With the vulnerable baseline locked in place, we can now run CVE Lite CLI against a dependency tree that actually contains known advisory matches.

Terminal showing npm list output with express@4.22.2 and lodash@4.18.1, followed by the clean reinstall and verification commands.

Next: Running cve-lite . against the pinned vulnerable versions to capture the actual findings, dependency path context, and generated fix commands.

Step 5: Running the Scan Against a Vulnerable Baseline (And Reading the Output)

After pinning the exact vulnerable versions (lodash@4.17.20 and express@4.17.1) and regenerating the lockfile, we ran the scanner:

cve-lite .

Here’s the actual output from our test environment:

>_ CVE Lite CLI (1.17.3)
────────────────────────────────
✔ Scan dependencies
✔ Highlight critical issues
✔ Show a clear fix plan

Fast. Local. Developer-first.

Advisory source: OSV (https://api.osv.dev)
Parsed 51 packages from package-lock (package-lock.json)
✓ Queried OSV in 1 batch
✓ Loaded 17 vulnerability detail records
⠙ Analyzing vulnerability findings 1/14: validating fix target for body-parser
⠹ Analyzing vulnerability findings 2/14: validating fix target for cookie@0.4.
⠸ Analyzing vulnerability findings 2/14: validating fix target for cookie@0.4.
⠼ Analyzing vulnerability findings 3/14: validating fix target for express@4.1
⠴ Analyzing vulnerability findings 4/14: validating fix target for lodash@4.17
⠦ Analyzing vulnerability findings 4/14: validating fix target for lodash@4.17
⠧ Analyzing vulnerability findings 5/14: validating fix target for path-to-reg
⠋ Analyzing vulnerability findings 7/14: validating fix target for send@0.17.1
⠙ Analyzing vulnerability findings 8/14: validating fix target for serve-stati
⠹ Analyzing vulnerability findings 8/14: validating fix target for serve-stati
⠸ Analyzing vulnerability findings 9/14: resolving remediation for body-parser
⠼ Analyzing vulnerability findings 10/14: resolving remediation for cookie@0.4
⠴ Analyzing vulnerability findings 11/14: resolving remediation for path-to-re
⠦ Analyzing vulnerability findings 12/14: resolving remediation for qs@6.7.0..
⠧ Analyzing vulnerability findings 13/14: resolving remediation for send@0.17.
⠇ Analyzing vulnerability findings 14/14: resolving remediation for serve-stat
✓ Analyzed vulnerability findings

────────────────────────────────
📦 Vulnerabilities found
────────────────────────────────

HIGH lodash@4.17.20
            Direct dependency
            Fix: upgrade to 4.18.0

HIGH body-parser@1.19.0
            Transitive dependency
            Fix: upgrade express to 4.22.0

HIGH path-to-regexp@0.1.7
            Transitive dependency
            Fix: upgrade express to 4.22.0

────────────────────────────────
🛠 Copy And Run These Fix Commands
────────────────────────────────

Detected package manager: npm (package-lock.json)
1 command group ready across 2 packages (1 high).
Validation: scanned 3 package versions; 2 are still known vulnerable.

High severity fix commands
> npm install express@4.22.0 lodash@4.18.0

────────────────────────────────
Summary
────────────────────────────────

8 packages · 17 CVEs
4 high · 1 medium · 3 low
2 direct · 6 transitive

✖ Scan complete. 4 urgent issues found.
Run with --verbose for fix plan, paths, and full table.

How to Read This Output (Without Getting Overwhelmed)

The scan completes in under 3 seconds and structures findings around action, not just awareness.

| Section | What it tells you | Why it matters for engineering teams |
| ----------------------------------------------- | ---------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| `Parsed 51 packages` | Scope of the dependency tree | Confirms the scanner is analyzing your actual lockfile, not a cached snapshot |
| `HIGH / MEDIUM / LOW` | Severity tier mapped to CVSS/OSV scoring | Enables triage by business impact, not just vulnerability count |
| `[Direct dependency] / [Transitive dependency]` | Ownership context | Tells you whether your team controls the fix or needs to coordinate with a parent package maintainer |
| `Fix: upgrade to X.Y.Z` | Exact, package-manager-aware command | Copy, paste, run. No advisory page hunting, no version guessing |
| `1 command group ready across 2 packages` | Consolidated remediation | Instead of multiple separate `npm install` commands, you get one grouped command that resolves multiple findings |

Key observation: The scanner identified that updating express@4.22.0 resolves both the body-parser and path-to-regexp transitive vulnerabilities. This parent-aware logic prevents the common anti-pattern of manually pinning transitive dependencies, which often breaks future semver resolution or introduces compatibility drift.

What This Means for Your Workflow

Before CVE Lite CLI, resolving these four high-severity findings would typically involve:

Opening each CVE link in a browser
Checking whether the vulnerability applies to your usage pattern
Determining if the package is direct or transitive
Researching the minimum safe version for each dependency
Constructing the correct npm install or npm update command
Testing whether the upgrade introduces breaking changes

With CVE Lite CLI, that workflow collapses to:

Run cve-lite .
Copy the suggested command: npm install express@4.22.0 lodash@4.18.0
Run it
Rescan to verify

That’s not automation replacing judgment. It’s tooling removing friction so engineers can focus on what actually requires human insight: impact assessment, compatibility testing, and release coordination.

Terminal output showing the structured finding list with severity badges, dependency types, and the consolidated fix command.

Step 6: Applying the Fix and Verifying the Result (Real Iterative Workflow)

CVE Lite CLI surfaced four high-severity findings and returned a consolidated remediation command. We applied the fix:

# Apply the consolidated fix command from Step 5
npm install express@4.22.0 lodash@4.18.0

npm upgraded both packages, updated the lockfile, and reinstalled affected transitive dependencies. Then we rescanned to verify:

cve-lite .

Here’s the actual output after the first round of fixes:

>_ CVE Lite CLI (1.17.3)
────────────────────────────────
✔ Scan dependencies
✔ Highlight critical issues
✔ Show a clear fix plan

Fast. Local. Developer-first.

Advisory source: OSV (https://api.osv.dev)
Parsed 70 packages from package-lock (package-lock.json)
Cache: 51 package match records, 17 advisory detail records
✓ Queried OSV in 1 batch
✓ Loaded 1 vulnerability detail record
✓ Analyzed vulnerability findings

────────────────────────────────
📦 Vulnerabilities found
────────────────────────────────

────────────────────────────────
🛠 Copy And Run These Fix Commands
────────────────────────────────

Detected package manager: npm (package-lock.json)
1 command group ready across 1 package (1 medium).

Medium severity parent upgrades
> npm install express@4.22.2

────────────────────────────────
Summary
────────────────────────────────

1 package · 1 CVE
1 medium
0 direct · 1 transitive

▲ Scan complete. 1 issue found.
Run with --verbose for fix plan, paths, and full table.

| Observation | What it means | Why it matters |
| ----------------------------------------------------- | ----------------------------------------------------- | ---------------------------------------------------------------- |
| `Parsed 70 packages (up from 51)` | New dependencies resolved during upgrade | Confirms the lockfile reflects the actual installed tree |
| `Loaded 1 vulnerability detail record (down from 17)` | Most findings resolved by the first fix | Shows measurable progress, not just “still broken” |
| `1 medium severity (down from 4 high)` | Risk reduced, not eliminated | Realistic expectation: remediation is iterative |
| `0 direct • 1 transitive` | Remaining issue is in a dependency of a dependency | Tells you the fix requires updating a parent, not pinning a leaf |
| `npm install express@4.22.2` | Consolidated command to resolve the remaining finding | One command, not three. Less cognitive load |

What This Output Tells You (And Why It’s Actually Good News)

Key insight: Dependency remediation is rarely a one-shot operation. You fix the highest-severity issues, rescan, and address the next layer. CVE Lite CLI makes this iterative loop visible and actionable — instead of hiding it behind a generic “run npm audit fix" suggestion.

Step 7: Applying the Final Fix

The scanner recommends a single command to resolve the remaining medium-severity finding:

# Apply the final parent upgrade
npm install express@4.22.2

Then rescan to confirm the tree is clean:

cve-lite .

Expected clean output:

>_ CVE Lite CLI (1.17.3)
────────────────────────────────
✔ Scan dependencies
✔ Highlight critical issues
✔ Show a clear fix plan

Fast. Local. Developer-first.

Advisory source: OSV (https://api.osv.dev)
Parsed 70 packages from package-lock (package-lock.json)
Cache: 51 package match records, 17 advisory detail records
✓ Queried OSV in 1 batch
✓ Loaded 0 vulnerability detail records
✓ Analyzed vulnerability findings

────────────────────────────────
📦 Vulnerabilities found
────────────────────────────────
✓ No known vulnerabilities found.

────────────────────────────────
Summary
────────────────────────────────

0 packages · 0 CVEs
0 high · 0 medium · 0 low

✓ Scan complete. All dependencies clean.

Verification: Cross-Check with npm Audit (Optional but Recommended)

To ensure alignment between scanning tools, cross-check with npm’s built-in audit:

npm audit

What This Means for Your Release Workflow

Before CVE Lite CLI, verifying a multi-stage fix required:

Running npm audit fix or manually constructing upgrade commands
Waiting for CI to re-run and report results
Checking dashboards to confirm findings were resolved
Often repeating the cycle if new transitive issues surfaced

With CVE Lite CLI, the loop collapses to:

Run cve-lite . → get fix command
Apply fix → rescan locally in seconds
Push when clean

That shift — from “wait for CI to tell me it’s broken” to “verify before I push” — is what reduces release friction and prevents vulnerable code from reaching review queues in the first place.

Terminal output showing post-fix scan with “No known vulnerabilities found” and clean npm audit output.

Step 8: Generating a Shareable HTML Report (For Compliance and Team Visibility)

Once the dependency tree is clean — or while findings still need remediation — teams often need to document the security posture for compliance audits, stakeholder updates, or handoff to other engineers. CVE Lite CLI can generate a self-contained HTML report that consolidates findings, fix commands, and severity summaries in a shareable format.

# Generate and automatically open HTML report
cve-lite . --report

Step 9: Testing Against Real-World Repositories (Beyond the Toy Project)

The minimal test project proved the workflow works. But engineering teams care about how tools behave against real codebases with complex dependency trees, monorepos, and transitive chains.

We tested CVE Lite CLI against three real projects to see how it scales:

Option A: OWASP Juice Shop (Deliberately Vulnerable)

OWASP Juice Shop is a deliberately insecure Node.js application designed for security training. It’s the perfect safe, legal target for testing vulnerability scanners.

# Clone Juice Shop
git clone https://github.com/juice-shop/juice-shop.git
cd juice-shop

# Install dependencies (this pulls in known vulnerable packages)
npm install

# Run CVE Lite CLI scan
cve-lite .

# Generate verbose output with full dependency paths
cve-lite . --verbose

# Create HTML report for documentation
cve-lite . --report ./juice-shop-report --no-open

Auto-Open in Browser

# Scan and automatically open report in your default browser
cve-lite . --report

This will:

Generate the HTML report in ./report directory (relative to your current working directory)
Automatically open report/index.html in your system's default browser
Keep the terminal free for other commands

Final Thoughts

Most vulnerability scanners are good at telling developers what’s broken.

Far fewer are good at telling them what to actually do next.

That’s where CVE Lite CLI feels different.

After testing it across both controlled environments and real-world repositories, the biggest takeaway wasn’t just that it detected vulnerabilities correctly — most modern scanners can do that. The real value was how much friction it removed from the remediation process itself.

Instead of:

digging through advisory pages
tracing transitive dependency chains manually
guessing safe upgrade versions
constructing install commands by hand

The workflow became:

cve-lite .

Copy the suggested fix command.

Run it.

Rescan.

Done.

That sounds simple, but simplicity is exactly what modern dependency security tooling has been missing.

The project also gets an important philosophical point right: developers are far more likely to fix vulnerabilities when the feedback loop happens locally, immediately, and inside their normal workflow — not hours later in a failing CI pipeline or buried inside a security dashboard.

And because the tool:

works offline
supports npm, pnpm, Yarn, and Bun
understands transitive remediation paths
integrates with SARIF and CI pipelines
generates shareable HTML reports
and now even plugs into AI coding assistants

…it fits naturally into both solo developer workflows and larger engineering environments.

Is it a replacement for full AppSec platforms? No.

It won’t detect malware hidden in packages before advisories exist. It won’t replace SAST, DAST, container scanning, SBOM management, or runtime protection. And it shouldn’t.

What it does instead is narrower — and arguably more useful day-to-day:

It helps developers fix dependency vulnerabilities faster, with less noise and less guesswork.

That’s a surprisingly important gap in the JavaScript ecosystem.

If your current workflow involves waiting for CI to fail, opening five browser tabs for every CVE, and manually piecing together remediation commands, CVE Lite CLI is absolutely worth testing.

Because at the end of the day, the best security tool is usually the one developers will actually use before they push code.