Skip to main content

How CVE Lite CLI Works

CVE Lite CLI is a local-first, metadata-only scanner. It operates directly within the developer's environment without requiring code uploads, cloud accounts, or heavy agent installations. It focuses on the moment of release — providing a fast, low-noise assessment of the dependency tree by analyzing resolved versions in project lockfiles.

CVE Lite CLI Workflow

Contents​

Trust boundary and privacy​

The scan is non-intrusive. Only package names and exact resolved versions are extracted from your lockfile. No source code, environment variables, secrets, or proprietary logic is ever transmitted to the external OSV API.

CVE Lite CLI does not require a hosted account, cloud dashboard, or source code upload.

For the full explanation, see Network Behavior and Privacy.

Lockfile-driven accuracy​

By parsing package-lock.json, pnpm-lock.yaml, or yarn.lock, the tool avoids the "it works on my machine" discrepancy. It scans the exact dependency tree that will be deployed — not what your package.json declares, but what was actually resolved and installed.

A limited package.json fallback is also supported for exact pinned direct dependencies when no lockfile is present.

Direct vs transitive triage​

The analysis engine uses the lockfile's graph structure to distinguish between:

  • direct dependencies — packages you declared in your manifest
  • transitive dependencies — packages brought in by your dependencies

This separation enables a "fix the root" strategy. Instead of chasing every nested vulnerable package, the tool surfaces the parent-level upgrade that resolves the underlying dependency path. In verbose mode, the full dependency path is shown so you can trace exactly how a transitive vulnerability was introduced.

Remediation strategy​

CVE Lite CLI turns findings into package-manager-native commands when the available metadata supports a confident path. Direct findings use validated package upgrades. Transitive findings prefer the parent package that introduced the vulnerable dependency, including npm-specific npm update <parent> recommendations when a known non-vulnerable child version already fits within the current parent range.

See the Remediation Strategy guide for the full decision model and package-manager notes.

Performance and caching​

A local TTL cache stores advisory results. This ensures that subsequent scans — common in iterative development or CI/CD retry loops — are near-instant and respect external API rate limits.

The local cache is especially useful in the scan-fix-rescan workflow where developers apply a fix and immediately rescan to confirm resolution.

Offline advisory flow​

Advisory data can be synced into a local SQLite database and reused for offline scans with zero runtime advisory API calls.

In a local benchmark, syncing ~217,065 advisory records improved from 87.53s to 8.84s after bulk SQLite ingestion optimizations — roughly 9.9x faster end-to-end.

See the Offline Advisory DB guide for full workflow details.

Standards-based output​

Results are available in JSON format for scripted pipelines, custom reporting, and artifact storage.

Use --json for JSON output.

SARIF output is planned — see issue #179 for progress.