Exposure: vulnerabilities and posture

Exposure management started with a bounded pass that matched whatever a host reported at enrolment against OSV. Before this wave, that meant almost nothing — enrolment only ever reported hostname, platform and architecture, so there was no real package data to match against. This wave gave sensors a real package-inventory channel, added a CISA Known Exploited Vulnerabilities cross-reference on top of the OSV match, and gave you CSV export and a tenant-wide posture number.

Per-host package inventory

A sensor reports its installed packages on an inventory channel event — name, version, architecture, source, and an ecosystem string where one applies (Debian, npm, PyPI, crates.io, Go, and so on). Not every package has an OSV ecosystem: rpm-installed packages, Windows registry uninstall entries and Windows hotfixes have no equivalent in OSV's vocabulary, so those are kept in the inventory for visibility — you can still see them on a host's package list — but they are never matched against OSV, because there is nothing in OSV's data to match them against.

Vulnerability matching now reads this real per-package inventory first, falling back to the older enrolment-derived data only for a host that has not yet reported an inventory event — so no tenant's existing findings regress while its fleet catches up to the new collector.

The CISA Known Exploited Vulnerabilities cross-reference

Alongside the OSV match, every finding is checked against CISA's Known Exploited Vulnerabilities catalogue — the published list of vulnerabilities CISA has confirmed are being actively exploited, not merely theoretically exploitable. A finding whose CVE appears on that list is flagged, with the due date CISA published for it.

A separate CVE enrichment source (NVD, for full CWE/CPE detail) was deliberately not built this wave — OSV's own data already carries CVSS scores where the advisory source provides one, and the KEV flag was judged the highest-value enrichment to add first.

Reading and exporting findings

The Exposure panel on XDR → Policy shows a findings table with a KEV pill per row, acknowledge and resolve actions, and a tenant posture-score pill. A host's own package list is reachable from its endpoint detail view — see Endpoint detail and applied policy.

A CSV export is available for vulnerability findings, carrying the CVE id, package name, installed and fixed versions, severity, CVSS score, the KEV flag, status, source and when it was first detected. This is the only surface in the security-configuration-assessment-and-exposure pair of features with a CSV export today — see Security configuration assessment for why SCA results do not have one yet.

The tenant posture score

A posture score is computed and recorded on a schedule — by default hourly, per tenant, bounded to a maximum number of assets per run so a large fleet does not turn one sweep into an unbounded job. Each run's score is recorded as a new history row rather than overwriting the previous one.

What to do next

1. Open the Exposure panel on XDR → Policy and sort by the KEV pill first — that is the strongest single remediation-priority signal it shows you.
2. Read Security configuration assessment for the other half of endpoint posture — configuration hardening rather than unpatched packages.
3. Read Endpoint detail and applied policy for a specific host's package list and findings together with its policy status.