cve.now adds a free CLI that checks lockfiles for known CVEs

Sazabi’s cve.now has a command-line tool that checks the lockfiles in a project for known CVEs, and groups what it finds by the upgrade that fixes them. On 11 November the official account called version 0.2.0 an upgrade, and the project’s creator, Sherwood, walked through the new check command on X.

cve.now is already a free, public feed that merges the CVE List, the GitHub Advisory Database, OSV, the US National Vulnerability Database, ENISA’s EUVD, CISA’s Known Exploited Vulnerabilities catalogue, FIRST’s EPSS scores and Exploit-DB into one entry per vulnerability. The CLI, published on npm under an Apache-2.0 licence, talks to the same public REST API as the site and its MCP server. No login or API key is required.

One command in the repo

The published entry point is npx cve.now check. It looks for supported lockfiles under the current directory, or under paths you pass it, and prints findings per lockfile. Each package line is grouped by an upgrade target, and labelled, where the files allow it, as a direct or transitive dependency, and as production or development. Sherwood’s point was a practical one: a critical finding in test tooling isn’t the same as one in authentication code.

For continuous integration, --fail-on can make the command exit with a failure when it sees a CISA KEV listing, or a finding the project rates as critical or high. The default is to exit successfully even when findings are present, so a CI job only breaks if you ask it to.

What leaves the machine

According to the project’s documentation, the CLI parses each lockfile locally and sends cve.now only the ecosystem, name and version of each package. Those checks are not stored. The documentation also says the tool doesn’t write files, run package managers or send telemetry. A separate path on the website lets you upload a lockfile to get a stack feed of later matches; that path is documented as deleting the file after parsing and keeping only the package list to build the feed.

A result with no matches means cve.now’s index has no known vulnerability for that version, not that the packages are safe. The project also notes that tools which read only OSV can list entries cve.now hasn’t merged yet.

Which lockfiles it accepts

The 0.2.0 documentation lists a wide set of lockfiles. Two of them come with documented limits: a flake.lock is checked by the git commit each input pins, through OSV, and package CVEs in nixpkgs are not checked; a requirements.txt is checked only for packages pinned to a single version.

Ecosystem	Lockfiles the CLI documents
JavaScript	package-lock.json, npm-shrinkwrap.json, bun.lock, pnpm-lock.yaml, yarn.lock
Python	poetry.lock, uv.lock, Pipfile.lock, requirements.txt
Rust, Go, Ruby, Elixir	Cargo.lock, go.sum, Gemfile.lock, mix.lock
PHP, .NET, Java, Nix	composer.lock, packages.lock.json, gradle.lockfile, flake.lock

What the feed already was

The same CLI can look up an entry by CVE, GHSA or OSV identifier, read the project’s feeds and rankings, and search the catalogue. Those commands map to operations already exposed on the MCP server at mcp.cve.now and on the public API. cve.now says its plain-English summaries are written by a model and labelled as such, while severity, exploitation status, affected versions and fixes come from the source records. It uses NVD data and says it isn’t endorsed by NVD.

Sherwood announced the check command, and the official account quoted that post as an upgrade:

New on @cvedotnow: a CLI

Run one command in your repo and see which dependencies have known CVEs, grouped by the upgrade that fixes them.

npx cve.now check

1- Tells you if each one is direct or transitive, prod or dev. A critical in your test tooling isn’t the same as one in your auth code

2- Fail CI on KEV, critical or high

3- Only package names + versions leave your machine. No login, no API key

— Sherwood (@shcallaway) November 11, 2026

🛡️ cve.now just got an upgrade!

— cve.now (@cvedotnow) November 11, 2026