# Cve Report

> Report which CVEs were fixed in each Questarr release by diffing package-lock.json across version tags and checking OSV.dev

- Skill: `doezer/cve-report` (Agent Skill)
- Install (CLI): `npx skillmds@latest add doezer/cve-report`
- Raw SKILL.md: https://api.skillmd.com/api/skills/doezer/cve-report/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: doezer (https://skillmd.com/u/doezer)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/doezer/cve-report

---


1. If the user asked about the full release history, run `node scripts/cve-report.mjs` (no args) — it walks every consecutive `v*` tag boundary plus the unreleased range from the latest tag to `HEAD`, diffing resolved `package-lock.json` versions (direct and transitive) and checking OSV.dev for CVEs fixed by each bump.
2. If the user asked about a specific version or range, run `node scripts/cve-report.mjs <fromTag> <toTag>` for just that boundary instead. List tags first with `git tag --list 'v*' --sort=v:refname` if the exact tag names aren't already known.
3. Present the script's output to the user as-is — it is already grouped per version boundary, then by scope (Production/Development dependencies) and severity (CRITICAL → HIGH → MODERATE → LOW → UNKNOWN) within each. Do not add, infer, or embellish CVE claims beyond what the script printed; OSV.dev is the source of truth here.
4. If the user wants the report saved, write it to `docs/CVE-REPORT.md` (or a path they specify). Do not auto-edit `docs/CHANGELOG.md` — CVE attribution needs human review before it becomes part of published release notes.
5. If the script errors (network failure reaching OSV.dev, a ref missing `package-lock.json`, etc.), report the specific error to the user rather than retrying blindly or guessing at results.