June 11, 2026 | Cybersecurity & QA

Shift Left, Further: Why CVE Lite CLI Finally Makes Local Security Scans Practical

I've written before about how AI is reshaping regression testing and why proactive testing—shifting left—matters just as much in cybersecurity as it does in functional QA. The logic is the same: find the problem as early as possible, fix it while the context is still fresh, and don't let it become someone else's incident ticket six months later.

So when I came across CVE Lite CLI, a new OWASP Foundation project, it immediately clicked. Not because it's another vulnerability scanner—there are plenty of those—but because of how it operates. And that makes all the difference.

The Problem with Pipeline-Only Security

Most dependency scanners sit in your CI/CD pipeline. You push code, wait for the build, and somewhere in the logs a scanner tells you about vulnerabilities you introduced hours (or days) ago. By then you've already moved on to the next ticket. The feedback loop is slow, and fixing becomes context-switching overhead.

If you've read my thoughts on AI-augmented testing or the Bridewell Threat Intelligence report, you know I believe in catching things before they compound. The same principle applies here.

What CVE Lite CLI Does Differently

CVE Lite CLI scans your lockfile locally—on your machine, in your terminal, in seconds. No account, no cloud upload, no CI run required. It parses npm, pnpm, Yarn, and Bun lockfiles, checks versions against the OSV advisory database, and tells you not just what's vulnerable, but what command to run to fix it.

The design philosophy is refreshingly practical: instead of drowning you in raw CVE IDs, it gives you copy-and-run npm install or npm update commands. And it understands transitive dependencies—if a vulnerable child package can be fixed by updating its parent within the existing version range, it tells you exactly that.

First Evaluation, Right After Implementation

This is the part that matters to me as a QA engineer. CVE Lite CLI puts the first security evaluation directly after the implementation step—not after the merge, not after the deployment, but right there in your local workflow. The developer (or the reviewer) runs a single command and knows within seconds whether their change introduced new vulnerabilities.

It turns dependency security from a CI gate into a local habit. That's a real shift-left move.

Putting It to the Test: A Real Project Scan

Let's make this concrete. I ran CVE Lite CLI against one of my current projects—a Next.js application called tama-gaming-v2. Here's what the initial scan looked like:

>_ CVE Lite CLI (1.21.0) ──────────────────────────────── ✔ Scan dependencies ✔ Highlight critical issues ✔ Show a clear fix plan Fast. Local. Developer-first. Advisory source: OSV (https://api.osv.dev) Parsed 529 packages from package-lock (package-lock.json) Cache: 695 package match records, 51 advisory detail records ✗ Found 11 packages (51 CVEs) with known OSV matches from package-lock ┌──────────┬──────┬────────┬─────┬─────────┐ │ Critical │ High │ Medium │ Low │ Unknown │ ├──────────┼──────┼────────┼─────┼─────────┤ │ 0 │ 5 │ 6 │ 0 │ 0 │ └──────────┴──────┴────────┴─────┴─────────┘ 🛠 Copy And Run These Fix Commands High severity fix commands ┌─────────┬─────────┬────────┬──────────────────┬────────────────────────┐ │ Package │ Current │ Target │ Versions scanned │ Still known vulnerable │ ├─────────┼─────────┼────────┼──────────────────┼────────────────────────┤ │ axios │ 1.13.6 │ 1.16.0 │ 5 │ 4 │ │ next │ 16.1.6 │ 16.2.6 │ 8 │ 7 │ └─────────┴─────────┴────────┴──────────────────┴────────────────────────┘ > npm install axios@1.16.0 next@16.2.6 High severity parent updates within range ┌─────────────┬─────────┬────────────────────┬─────────────────────────────────┐ │ Package │ Current │ Recommended target │ Context │ ├─────────────┼─────────┼────────────────────┼─────────────────────────────────┤ │ flatted │ 3.3.4 │ lockfile refresh │ flat-cache@4.0.1 allows │ │ │ │ │ flatted@3.4.2 within range │ │ picomatch │ 4.0.3 │ lockfile refresh │ micromatch@4.0.8 allows │ │ │ │ │ picomatch@2.3.2 within range │ └─────────────┴─────────┴────────────────────┴─────────────────────────────────┘ > npm update flatted && npm update picomatch Medium severity parent updates within range ┌──────────────────────┬─────────┬────────────────────┬─────────────────────────┐ │ Package │ Current │ Recommended target │ Context │ ├──────────────────────┼─────────┼────────────────────┼─────────────────────────┤ │ @tailwindcss/postcss │ 4.2.1 │ lockfile refresh │ allows postcss@8.5.15 │ │ brace-expansion │ 5.0.4 │ lockfile refresh │ minimatch allows 5.0.6 │ │ ws │ 8.19.0 │ lockfile refresh │ @supabase/realtime-js │ │ │ │ │ allows ws@8.21.0 │ └──────────────────────┴─────────┴────────────────────┴─────────────────────────┘ > npm update @tailwindcss/postcss && npm update brace-expansion && npm update ws

Eleven packages, 51 CVEs total. Five high-severity findings, six medium. The tool didn't just list them—it grouped them by actionability and printed the exact commands to run. That's the key difference.

Applying the Fixes

I ran the suggested commands. No research, no manual CVE lookup, no figuring out dependency trees:

$ npm install axios@1.16.0 next@16.2.6 $ npm update flatted && npm update picomatch $ npm update @tailwindcss/postcss && npm update brace-expansion && npm update ws

Every command completed without breaking changes. The parent-aware updates respected version ranges, so nothing in the project actually broke—it was a pure lockfile refresh in most cases.

The Result: 51 CVEs → 1 CVE

51 CVEs before 5 high · 6 medium
1 CVE after 0 high · 1 medium

Here's the final scan after applying the fixes:

>_ CVE Lite CLI (1.21.0) ──────────────────────────────── ✔ Scan dependencies ✔ Highlight critical issues ✔ Show a clear fix plan Fast. Local. Developer-first. ✗ Found 1 package (1 CVE) with known OSV matches from package-lock ┌──────────┬──────┬────────┬─────┬─────────┐ │ Critical │ High │ Medium │ Low │ Unknown │ ├──────────┼──────┼────────┼─────┼─────────┤ │ 0 │ 0 │ 1 │ 0 │ 0 │ └──────────┴──────┴────────┴─────┴─────────┘ Showing medium+ findings in the main table. ┌─────────┬─────────┬──────────┬────────────┬──────────┬─────────────────────┐ │ Package │ Version │ Severity │ Type │ Fixed │ IDs │ ├─────────┼─────────┼──────────┼────────────┼──────────┼─────────────────────┤ │ postcss │ 8.4.31 │ medium │ transitive │ 8.5.10 ⊘ │ GHSA-qx2v-qp2m-jg93 │ └─────────┴─────────┴──────────┴────────────┴──────────┴─────────────────────┘ ⊘ Advisory hint only — no automated fix command could be generated.

From 51 CVEs down to 1. The remaining issue is a transitive postcss dependency that doesn't have an automated fix path yet—but it's a medium-severity advisory hint, not a blocker.

The total time from first scan to clean project? About two minutes. That's what local-first looks like.

The Automation Angle: Closing the Loop

Here's where it gets even more interesting for my workflow. Because CVE Lite CLI is a CLI tool with structured output, it's trivially integrable into automated agent workflows. Imagine:

  • A pre-commit hook runs cve-lite on staged changes and warns if new vulnerabilities appear
  • A CI step scans and, if vulnerabilities are found, triggers an AI agent that reads the fix commands, applies them, and opens a PR
  • A scheduled agent re-scans nightly and automatically creates fix PRs for any new advisories

This is the automation loop I talked about in my post on AI in regression testing—the same principle applies to security. Let machines handle the repetitive detection-and-fix cycle. The developer reviews and approves. The feedback loop stays tight, the effort stays small, and vulnerabilities never accumulate.

This is proactive testing in practice. Not waiting for a pipeline to tell you something is wrong. Not relying on a security team to triage your dependency tree. Running the check yourself, locally, at the moment it matters most—right after you make the change.

Wrapping Up

CVE Lite CLI isn't trying to replace Snyk or Dependabot or npm audit. It fills a different niche—the local, immediate, low-friction feedback loop that makes security scanning a natural part of development rather than a gate to dread.

For anyone who practices shift-left testing, this tool is a natural addition to the toolbox. Install it, run it after your next npm install, and see what turns up. The fix commands are already waiting for you.

📖 OWASP CVE Lite CLIGitHub

#ShiftLeft #DevSecOps #OWASP #CVELiteCLI #SoftwareSecurity #ProactiveTesting #QA #QualityEngineering #Automation
← Back to Insights