Announcing Vulnerability Reporting: exposure insight from the telemetry you already collect

Most security teams already run EDR across their entire fleet. Those sensors report process activity, network connections, file events, and the full software inventory of every endpoint they cover. So when a new CVE lands and someone asks whether the organization is exposed, the data needed to answer already exists in the platform. The friction is that answering the question has traditionally meant standing up a parallel program to collect information you are already collecting: a separate vulnerability scanner, another agent on every host, and a second inventory that has to be reconciled against the one your EDR already maintains.

Vulnerability Reporting, now generally available for every LimaCharlie organization, removes that duplication. It reads the software inventory your sensors already collect and matches it against a continuously updated CVE database at cve.limacharlie.io, so vulnerability posture becomes one more capability built directly into the SecOps cloud platform. There is no new agent to deploy and no second console to maintain. The price is $0.05 per EDR sensor per month, with no per-scan fees or separate scanner licensing.

From software inventory to exposure

The extension reads package data from your existing sensors across Linux (deb and rpm), macOS, and Windows, then translates that inventory into a live view of where your fleet is exposed.

A dashboard gives you the at-a-glance picture: total findings, known exploited vulnerabilities, open critical findings, findings on hosts you have tagged as critical, mean time to resolution by severity, an overall exposure score, and a burndown view that shows whether remediation is reducing risk over time. Two views sit underneath it. You can work the data from the CVE side to ask which vulnerabilities you are exposed to and how many hosts each one touches, then pivot to the endpoint side to see every machine affected and the specific packages responsible. Filtering, search, sorting, and pagination run throughout, so a question like "show me every open critical KEV on production systems" is a few clicks rather than a reporting exercise.

For each finding, the extension resolves the fix version: the package release that actually closes the gap. That turns a vulnerability list into a concrete set of remediation actions your team prioritize and execute. When you want the data elsewhere, you can export it in several formats, including a ready-to-use remediation plan.

Prioritization that reflects your environment

A raw CVSS score tells you how serious a vulnerability is in the abstract, but it cannot tell you what to fix first across your specific fleet. Vulnerability Reporting computes an LC Risk score from 0 to 100 for every finding by blending four signals:

• Base severity of the CVE.

• EPSS, the real-world probability the vulnerability will be exploited, with history so you can watch the trend move.

• CISA KEV, which raises the score for vulnerabilities already being exploited in the wild.

• Asset criticality, your own operational context layered on top.

That last signal is what makes the score yours rather than generic. Tag hosts with lc:asset:* tags for criticality, exposure (internet-facing, DMZ, internal), and environment (prod, staging, dev), and the score weights accordingly. A critical CVE on an internet-facing production server ranks far above the same CVE on a developer laptop, automatically. For an MSSP tracking exposure across dozens of client tenants, this means a single place to see which customers are exposed to a newly weaponized CVE, ordered by what matters in each of their environments.

Managing findings down to zero

Surfacing vulnerabilities is the easy part. Vulnerability management done well is an ongoing operational discipline, and that is where most programs stall, so the extension builds the full lifecycle in.

You can resolve a finding as mitigated, accepted, or false_positive. Risk acceptance takes an optional expiry date, so accepted risk does not quietly become permanent. Bulk actions let you apply a resolution to up to 100 findings at once, and the open-versus-resolved state stays explicit: reopening is a single action, and your resolution state overlays cleanly on top of each fresh scan. Daily snapshots feed the burndown view, giving you open findings by severity over time so you can show stakeholders that remediation work is moving the needle.

When you patch, you do not have to wait for the next scheduled scan to confirm it. Trigger a rescan to reevaluate an endpoint immediately, or reset findings to rebuild the inventory from scratch when a host's packages have changed significantly.

Getting started

1. Add the Vulnerability Reporting extension to your organization

2. Confirm your sensors are reporting package inventory (most already are)

3. Tag your assets with lc:asset:* tags to sharpen prioritization

4. Open the dashboard and start triaging

For the most reliable inventory and findings, upgrade 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.

Vulnerability Reporting is available now. Full documentation lives in the Vulnerability Reporting docs. 

As you put it to work, we would value your read on which views, filters, or integrations would make it more useful for your team.