Who is using CVE Lite CLI? Share your use case

[sonukapoor]

If you are using CVE Lite CLI in your projects or at your company, we would love to hear about it.

Drop a comment below with:

• Where you use it — local dev, CI pipeline, pre-commit hook, security review workflow, etc.
• What lockfile / package manager — npm, pnpm, Yarn, Bun
• What problem it solved — anything from catching a specific CVE to making vulnerability scanning part of your daily workflow

No need for a long writeup — even a sentence or two helps.

This thread helps the community discover real-world adoption patterns and helps us understand where CVE Lite CLI is most useful. It also supports our goal of growing toward OWASP Lab Project status.

If you are using CVE Lite CLI in a public repo, please consider adding the CVE Lite CLI badge to your repo. It helps other projects discover the tool and shows the community who's using it: https://github.com/OWASP/cve-lite-cli#add-a-badge-to-your-project

Thanks for being part of the project.

[ManuelRauber]

I'm using it for LehrGrapht. It runs exclusively in the CI pipeline with each run to check early if there is something wrong. For the normal pipelines that builds/deploys I'm using with fail-on: 'critical'. In another independent action that is exclusive for the CVE check, I let it fail on high.

[sonukapoor]

Thanks @ManuelRauber - Are you also using the CLI locally in your developer workflow?

[ManuelRauber]

Thanks @ManuelRauber - Are you also using the CLI locally in your developer workflow?

I only use the CLI in the CI pipeline, because it builds the final artifact that will be deployed. At that point I want to make sure it does not contain a critical CVE.

[alamb-hex]

CVE Lite is the third ScanSource in HexOps (https://github.com/Hexaxia-Labs/hexops) (our open source dev ops dashboard) alongside Grype and pnpm-audit. It runs on every project audit in local dev and CI across about 30 active projects, mostly pnpm with some npm.

Two concrete wins for us:

1. The postcss-under-Next case where npm audit fix --force wanted to downgrade Next.js but CVE Lite correctly identified the parent-pin floor as the right form of fix. That guidance held up across every subsequent re-resolution.

2. Your --offline-db fallback caught a silent-zero-findings bug in our wrapper code (live API timed out, no output file written, wrapper read empty as clean). We now run online-first with --offline-db fallback and throw on empty output. That fix surfaced a live qs CVE-2026-8723 that had been masked for weeks.

The remediation-first design and the parent-graph walking compose well with how we already think about dependency hygiene. Rooting for Lab status. It's earned.

Full writeup: https://labs.hexaxia.tech/blog/hexops-cve-lite-integration/

[luisoria]

I recently tested the CVE Lite CLI across several repositories and was thoroughly impressed by its efficiency. As a cybersecurity architect, I deal with dependency management and vulnerability analysis constantly, and what stood out to me most was how fast and precise the tool is at analyzing local lockfiles. Its ability to clearly map the dependency graph against OSV data and provide direct, actionable remediation paths for JS/TS projects is outstanding. It stays true to its 'lite' philosophy, avoiding the bloat of heavier platforms while delivering exactly what developers need in their workflow. I see this as a highly practical and valuable contribution to the OWASP ecosystem. It definitely has my full support on its path toward OWASP Lab graduation. Great work, Sonu and team!

[drmoreira]

We are currently using CVE Lite CLI to monitor security across several of our projects, handling both npm and Yarn lockfiles.

Right now, it fits perfectly into our local dev workflow, and we are evaluating integrating it as a pre-commit hook in the near future. The biggest value for us is the ability to catch security issues as early as possible in the development cycle, and this tool is ideal for providing that fast, local feedback loop.

Great work on the project, happy to support the path to OWASP Lab status!

[sonukapoor]

Thank you for sharing @drmoreira

[mmagdy88]

Using CVE Lite CLI on a production TypeScript project

Sharing how I've been using cve-lite-cli.

Context: I run servarat.net and maintain a React + Vite + TypeScript frontend (shadcn/ui, React Router, the usual transitive sprawl). I wanted a fast pre-push vulnerability check that lives in my terminal, not at the end of a CI pipeline.

How I run it: straight from the project root, no install —

npx cve-lite-cli . --verbose

First run pulls the package, after that rescans are near-instant. Nothing leaves the machine.

What stood out vs npm audit:

1. Copy-and-run fix commands. Instead of a list of advisory IDs, I get scoped commands per package (npm install vitest@4.1.0, etc.). The distance between "you have a problem" and "here's the exact command" is basically zero.
2. Parent-aware transitive handling. This is the part I hadn't seen elsewhere. It separates "your range already allows the fix, just refresh the lockfile" (npm update brace-expansion) from "you need to bump the parent package" (react-router-dom@6.30.4 rather than chasing react-router directly). That's the manual npm ls reasoning I'd normally do by hand.
3. Direct vs transitive split up front, so I can triage what I own versus what comes through a dependency immediately.

Real result: I didn't just scan — I applied the full remediation plan on the same project afterward (patched postcss/react-router/brace-expansion, did the Vite 6 + Vitest 4 majors deliberately with build/test smoke checks). The fix plan held up; the rescan came back clean apart from a residual advisory the tool itself had already flagged on the upgrade target, which I appreciated the honesty on.

I wrote the whole process up in detail here, including the npm audit side-by-side and the toolchain upgrade gotchas: https://blog.servarat.net/i-ran-owasp-cve-lite-cli-on-a-real-typescript-app-heres-what-it-actually-told-me/

Nice work on this — it fits the gap where I actually make decisions (the terminal, before the commit) instead of nagging from a dashboard I've learned to ignore.

[sonukapoor]

Thank you for sharing your use case @mmagdy88

[m2papierz]

Where: We use CVE Lite CLI in (github.com/latchgate-ai/latchgate) CI pipeline - hard gate on every PR and merge to main.

Package manager: npm (TypeScript SDK). We pin the action by commit hash and run it with fail-on: high.

What it solves: LatchGate is an execution security kernel for AI agents. The project ships Rust crates, a Python SDK, and a TypeScript SDK, so we need vulnerability coverage across all three ecosystems. CVE Lite CLI covers the npm side, it sits alongside cargo audit + cargo deny for Rust and pip-audit for Python, plus a 7-day dependency freshness check that rejects anything published too recently (supply-chain hygiene).

For a project whose entire point is enforcing security boundaries around untrusted code, shipping a dependency with a known high-severity CVE is unacceptable. CVE Lite CLI makes that a build failure instead of the exposure. Good tool, glad it exists.

[sonukapoor]

Thank you so much for sharing this, @m2papierz - this is exactly the kind of real-world deployment story that matters. Using CVE Lite CLI as a hard gate in a security kernel for AI agents is a compelling use case. Really appreciate you taking the time to document it here.

One small ask - would you consider adding the CVE Lite CLI badge to your repo? It helps other projects discover the tool and shows the community who's using it: https://github.com/OWASP/cve-lite-cli#add-a-badge-to-your-project

[m2papierz]

Sure, will add it :)

[WSWATERMAN]

Thank you for this tool and the goal of the project. I have been developing a Universal shell called akaSHa "Akasha" for DevOps / Production support teams. At this time I am integrating this tool into my shell.

Universal AI Core Terminal: Driven by the next-generation google-genai automation engine for contextual code translation, intelligence parsing, and direct environment feedback loops.
Adaptive Local Training Engine (LLM Optimization): Captures and evaluates historic execution telemetry and user feedback directly on the edge. This localized training cache dramatically optimizes token consumption pipelines, bypassing external cloud LLM API roundtrips for redundant command structures.
Stateful Confidence Telemetry Caching: Leverages an isolated local SQLite layer (.akasha_private.db) to log transactional executions, automatically intercepting recurring natural language intents and resolving them locally with near-zero latency whenever confidence thresholds are met (>= 80%).
Secure SSH Terminal Wrapping: Integrates paramiko under the hood to establish persistent channels, enabling interactive remote execution and full AI-interception workflows over secure connections.

https://github.com/WSWATERMAN/Omni-Ever-Expanding-Nebula-Noodle

[sonukapoor]

Thank you, if useful, please also add your company name.

One small ask - would you consider adding the CVE Lite CLI badge to your repo? It helps other projects discover the tool and shows the community who's using it: https://github.com/OWASP/cve-lite-cli#add-a-badge-to-your-project