Osquery Vulnerability Detection: What It Can and Cannot Do

Osquery vulnerability detection has a clean split most teams blur: it tells you what is installed with certainty, and it tells you nothing about what is exploitable.

That distinction is the whole story. A scanner probes from the network and infers what version you are running. Osquery reads the package database on the host and knows. For inventory, that is a real upgrade in accuracy. But knowing that a vulnerable version is present is not the same as knowing it can be attacked, and a vulnerability program that treats the first as the second drowns in findings that do not matter.

So use osquery for what it is good at, understand exactly where it stops, and put deliberate work into the gap. This piece walks the full path: which tables to read, how to turn inventory into findings, and why the version list is the start of the job rather than the end of it.

What can osquery detect about vulnerabilities?

Osquery gives you ground truth for installed software, which is the raw material every vulnerability decision depends on. The tables that carry it are stable and boring in the best way:

• deb_packages and rpm_packages for Debian and Red Hat family Linux, with exact name and version.
• apps and homebrew_packages on macOS, programs on Windows.
• os_version and kernel_info for the platform build and kernel, which drive kernel level exposure.
• python_packages, npm_packages, and the browser extension tables for the language and application layers where supply chain problems keep appearing.

A single query answers the exposure question a scanner takes a full window to guess at:

SELECT name, version FROM deb_packages
WHERE name = 'openssl';

Run that across the fleet with a live query and you know, precisely, every version of OpenSSL you are running, straight from dpkg. No inference, no scan schedule. The complete table reference is in our guide to the most useful osquery tables, and the query mechanics are in writing osquery queries.

How do you turn inventory into vulnerability findings?

Here is the step people expect osquery to do and it does not: mapping a package version to a CVE. Osquery has no built in vulnerability feed. It reports that you run OpenSSL 3.0.2. Deciding that 3.0.2 is affected by a specific advisory requires correlating that version against an external source.

The reference vuln-management pack is honest about this. Read it and every query, from deb_packages to kernel_info, carries the same note: useful "with the help of a vulnerability feed." The pack collects. The feed decides. The official osquery guide to managing CVEs describes the correlation model in more detail. We break down the pack itself in osquery query packs.

The feed side has moved recently in a way worth knowing. Distribution security data used to lean on OVAL definitions, which were per vendor and awkward to consume. The ecosystem is shifting toward OSV, an open, machine readable vulnerability database with a common schema across ecosystems. Fleet, for one, moved its Ubuntu correlation from OVAL toward OSV feeds in 2026. If you are building your own correlation, OSV is the format to target rather than stitching together vendor specific files.

The build pattern, then, is two stages. Osquery collects the installed inventory on a schedule. A correlation job matches that inventory against an OSV or NVD feed and produces findings. Keep those stages separate. The collection is stable; the feed changes daily, and you want to re-evaluate old inventory against new advisories without re-querying every host.

Why does a matched CVE still produce false positives?

A version match is a suspicion, not a verdict. A package being installed says nothing about whether the vulnerable code is loaded, whether the service is running, or whether anything can reach it. This is the exact failure mode of legacy scanning, and it is why teams end up with backlogs of thousands and a nagging sense that most of it is noise. We took this apart in why your CVE scanner is flying blind.

Osquery is unusually good at closing that gap, because the context lives in tables right next to the inventory. You can join the package list against what is actually running and listening:

SELECT p.name, p.version, lp.port, lp.address
FROM deb_packages p
JOIN processes proc ON proc.name = p.name
JOIN listening_ports lp ON lp.pid = proc.pid
WHERE p.name = 'nginx';

That query does not just tell you nginx is installed. It tells you nginx is running and which interface it listens on. A vulnerable nginx bound to an external address is a different problem from the same version sitting unused on disk, and the difference is the whole point of prioritization. This is the same argument we make about severity scores in CVSS vs EPSS: the score is a starting input, and exposure is what turns it into a decision. For cutting the resulting noise without missing real risk, see reducing false positives in vulnerability management.

Why this matters more than it used to

The urgency is not manufactured. The 2026 Verizon Data Breach Investigations Report found vulnerability exploitation had become the leading initial access vector at 31 percent of breaches, ahead of credential abuse for the first time. On the other side, CISA's Known Exploited Vulnerabilities catalog passed 1,480 entries at the end of 2025, up roughly 20 percent in a year per SecurityWeek. Attackers are exploiting known bugs faster, and the list of bugs known to be exploited keeps growing.

That combination rewards precise, continuous inventory and punishes stale scans. If you can answer "which hosts run a version on the KEV list, and which of those actually expose it" in minutes, you can act inside the window that matters. If that question takes a scan cycle and a spreadsheet, you are defending last week.

A worked approach

Putting it together into something you can operate:

• Schedule the inventory tables for your platforms so every host reports installed software continuously.
• Run a correlation job that matches that inventory against an OSV or NVD feed, refreshed daily.
• Enrich each match with context from the activity tables: is the code loaded, is the service running, is a port exposed.
• Cross reference matches against the CISA KEV catalog to flag the ones with confirmed exploitation.
• Rank by exposure and known exploitation, not by CVSS alone, and hand engineers a short list instead of a dump.

The first two steps are mechanical. The third is where most programs stall, because joining and interpreting host context at fleet scale is exactly the judgment work that does not automate itself with a query. That is the problem Artemes AI is built around: pairing deep endpoint context with AI driven analysis that reads the real system state to decide which findings are exploitable here, and what the fix is, rather than forwarding every version match a query can produce. Osquery supplies the truth. Something still has to reason over it.

Frequently asked questions

Does osquery scan for vulnerabilities by itself?

No. Osquery collects accurate software and system inventory. Detecting vulnerabilities requires correlating that inventory with an external vulnerability feed such as OSV or the NVD. Osquery provides the ground truth, not the CVE mapping.

Which osquery tables matter most for vulnerability detection?

The package tables (deb_packages, rpm_packages, programs, apps), the platform tables (os_version, kernel_info), and the activity tables (processes, listening_ports) that tell you whether vulnerable code is actually running and exposed.

Is osquery more accurate than a network scanner?

For installed software inventory, yes, because it reads the package database directly instead of inferring versions from the network. It does not replace network scanning for finding unmanaged hosts, and it still needs a feed to map versions to vulnerabilities.

How do you avoid false positives with osquery vulnerability detection?

Join the inventory against the activity tables so a finding reflects code that is loaded, running, and reachable, not merely present on disk. Presence alone is the most common source of false urgency.

The takeaway

Use osquery to know exactly what is installed everywhere, then treat that inventory as the input to a real pipeline: correlate it with an OSV or NVD feed, enrich each match with whether the code is running and exposed, and rank by exploitation and reachability rather than raw severity. Osquery removes the guesswork from the one question scanners get wrong most often. What you build on top of that certainty is what turns a vulnerability list into a defensible remediation plan.