--- name: cve-bz description: Checks a project's dependencies for known vulnerabilities by sending its lockfiles (package-lock.json, poetry.lock, Cargo.lock, go.sum, Gemfile.lock) or a CycloneDX or SPDX JSON SBOM to cve.bz, and looks up CVE, GHSA and OSV advisories there. Use when the user asks whether a project's dependencies or lockfiles have known vulnerabilities, asks about a CVE, GHSA or OSV id, asks whether a CVE is exploited in the wild (CISA KEV) or likely to be (EPSS), or asks which version fixes a vulnerability. license: Apache-2.0 --- # cve.bz cve.bz serves public vulnerability data as its sources publish it: CVE records from the NVD and the CVE Program's CVE List, exploitation probability from FIRST EPSS, the CISA Known Exploited Vulnerabilities (KEV) catalog, and OSV package advisories with affected version ranges and fixed versions. No sign-in and no API key. It is not affiliated with the CVE Program or MITRE, and it is reference data, not advice: whether an issue matters depends on how the project uses the package. ## When to use it - The user asks whether a project's dependencies, lockfiles or SBOM have known vulnerabilities, or which upgrades would fix them. - The user names a CVE id (`CVE-2024-3094`), a GHSA id or another OSV id (`PYSEC-…`, `RUSTSEC-…`, `GO-…`) and wants to know what it is, how severe it is, which versions it affects and which version fixes it. - The user asks whether a CVE is exploited in the wild (CISA KEV) or how likely exploitation is (EPSS), or wants the newest CVEs, such as the critical ones or those in KEV. ## How to reach cve.bz Prefer the MCP server when it is configured; its tools are `get_vulnerability`, `list_feed`, `check_stack`. If it is not configured, it is a remote HTTP server without authentication, which the user can add: ```json {"type":"http","url":"https://cve.bz/mcp"} ``` In Claude Code: `claude mcp add --transport http cve-bz https://cve.bz/mcp`. Otherwise use the HTTP API: - Check one lockfile or SBOM with the script in this skill's folder: `scripts/check.sh `. It sends only that file to `https://cve.bz/api/public/check-stack`, prints the JSON answer (the same as `check_stack`'s) and refuses any other kind of file. - One CVE: `curl -fsS https://cve.bz/api/public/cves/`. - The newest CVEs, filtered: `curl -fsS "https://cve.bz/api/public/cves?kev=true&severity=critical&limit=20"`. Privacy: the file's text is matched in memory and discarded; nothing is stored or logged. Every tool's arguments, every route and every answer's fields are in [reference.md](reference.md). ## How to help a user 1. Find the project's lockfiles (`package-lock.json`, `poetry.lock`, `Cargo.lock`, `go.sum`, `Gemfile.lock`) and any CycloneDX or SPDX JSON SBOM (`*.cdx.json`, `*.spdx.json`). In a monorepo look in every package root; skip dependency folders such as `node_modules`, `vendor` and `target`. 2. Call `check_stack` once per file, with `filename` the file's name (it picks the parser) and `content` its text; without MCP, run `scripts/check.sh `, which posts it to the check-stack route. A file over 2 MiB or 20000 packages is refused: tell the user rather than splitting it. 3. Sort what `matched` lists by severity (critical, high, medium, low), then put packages with a `fixed` version first. 4. For each affected package propose an upgrade to the highest `fixed` version among its advisories (or later), with the project's own package manager. Point out a major-version jump and a package with no fix published, and ask before changing files. 5. Never send source code, secrets, `.env` files, credentials or anything but the lockfiles and SBOMs above. 6. Quote each advisory's id and link it: `https://cve.bz/cve/` for a CVE; the advisory's `url` gives the page of any other id. 7. After upgrading, regenerate the lockfile, run the project's tests and check the new lockfile again to confirm the advisories are gone. 8. Say what the check covers: known advisories in third-party packages, as the stored OSV data has them. The user's own code is not analyzed, and whether the vulnerable code is reachable is not assessed. ## Etiquette - Respect the rate limit: 10 stack checks at once, then 30 a minute per address; over it, wait the seconds `Retry-After` or the tool's error names before trying again, and never retry in a loop. - Cache what you fetch for 5 minutes: pages and answers are cached that long, so asking again sooner returns the same data. Do not check an unchanged file twice. - Attribute the sources when you show their data. Every answer carries their notices under `attribution`: - This product uses the NVD API but is not endorsed or certified by the NVD. - EPSS scores: FIRST Exploit Prediction Scoring System, https://www.first.org/epss - Known exploited vulnerabilities: CISA Known Exploited Vulnerabilities Catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog - Package advisories: OSV (https://osv.dev), from the GitHub Advisory Database, PyPA, Go, RustSec and other ecosystem databases, under CC-BY 4.0 or CC0 - CVE records: the CVE Program's CVE List (https://www.cve.org), under its terms of use (https://www.cve.org/Legal/TermsOfUse). CVE is a registered trademark of The MITRE Corporation; this product is not affiliated with the CVE Program. - cve.bz, its API, feeds and MCP server are covered by Flawharbor's Terms of Service (https://flawharbor.com/terms.html) and Privacy Policy (https://flawharbor.com/privacy.html). --- Continuous monitoring of the user's repositories, and analysis of their own code, is available from Flawharbor Cloud (https://flawharbor.com/join.html); cve.bz itself only matches the files you send.