Now GA: Vulnerability Reporting, built right into LimaCharlie
Hey everyone,
We’re excited to announce that the Vulnerability Reporting extension (ext-vulnerability-reporting) is now Generally Available for all LimaCharlie organizations.
You already have sensors deployed across your fleet collecting telemetry. Those same sensors already know every package installed on every endpoint. So why stand up a separate vulnerability scanner, push another agent, and reconcile two inventories? Vulnerability Reporting turns the EDR data you already collect into a continuously-updated view of your exposure — no extra agent, no extra deployment.
And the price is hard to argue with: $0.05 per EDR sensor per month. That’s it. No per-scan fees, no separate scanner licensing, no surprise overages.
What it does
The extension reads the software inventory from your existing sensors (Linux deb/rpm packages, macOS, and Windows) and matches it against our continuously-updated CVE database at cve.limacharlie.io. From there you get:
- CVE-centric and endpoint-centric views — pivot from “which CVEs am I exposed to?” to “which hosts are affected?” and back, with filtering, search, sorting, and pagination throughout.
- A vulnerability dashboard for an at-a-glance picture of your org’s posture.
- Fix-version resolution — for each finding, we tell you the package version that actually closes the gap, so remediation is a concrete action, not a research project.
Prioritization that reflects your environment
Raw CVSS severity doesn’t tell you what to fix first. Vulnerability Reporting computes an LC Risk score (0–100) per finding that blends:
Base severity
EPSS — the real-world probability the CVE will be exploited (with EPSS history so you can see the trend)
CISA KEV — a boost for vulnerabilities known to be exploited in the wild
Asset criticality — your own context
That last one is the differentiator. Tag your hosts with lc:asset:* tags — criticality, exposure (internet-facing / dmz / internal), environment (prod / staging / dev) — and the risk score weights accordingly. A critical CVE on an internet-facing prod box ranks far above the same CVE on a dev laptop, automatically.
A real remediation workflow
Finding vulnerabilities is easy. Managing them down is the hard part, so we built the lifecycle in:
- Resolve findings as
mitigated,accepted(risk acceptance, with an optional expiry date so accepted risk doesn’t quietly become permanent), orfalse_positive. - Bulk actions — apply a resolution to up to 100 findings at once.
- Open vs. resolved is explicit — reopening is one action, and your resolution state overlays cleanly on top of fresh scan data.
- Daily snapshots and a burndown view — track open findings by severity over time so you can show your remediation work is actually moving the needle.
Getting started
- Add the Vulnerability Reporting extension to your org from the Extensions page.
- Make sure your sensors are reporting package inventory (most already are).
- Optionally tag your assets with
lc:asset:*tags to sharpen prioritization. - Open the dashboard and start triaging.
Full documentation is here: Vulnerability Reporting docs
That’s it — no new agent, no separate console, no extra infrastructure on your side.
One recommendation: for the most reliable package inventory and findings, we suggest upgrading your sensors to the latest version. Newer sensors collect a more complete and accurate software inventory, which directly improves the quality of your vulnerability data.
We’d love your feedback as you put it to work. What views, filters, or integrations would make this more useful for your team? Drop a reply below. 
Happy hunting,
The LimaCharlie Team