osquery

osquery exposes operating system state as relational tables you query with SQL. Running processes, open sockets, installed packages, logged-in users, kernel modules, and scheduled tasks are all tables, and questions about a system become queries:

SELECT name, path FROM processes WHERE on_disk = 0;

That one finds processes whose executable no longer exists on disk — a classic indicator of a deleted-binary implant, and a genuinely awkward thing to establish with conventional tools.

Why the abstraction is a good one

The alternative is a different tool per question, each with its own output format needing parsing. osquery makes the whole system one interface, which has two consequences worth the adoption cost.

Questions compose. Joining processes against listening_ports against users answers questions no single-purpose tool was built for, without writing a script.

It works identically across platforms. The same query runs on Linux, macOS, and Windows. For a mixed fleet this is a substantial simplification, and it is rare.

At fleet scale a management layer distributes queries to all hosts and aggregates results, so “which machines have this vulnerable package” is one query rather than a loop over an inventory.

The limitation that matters

A query is a point-in-time snapshot. osquery answers what is true now, not what happened. A process that ran for two seconds an hour ago left no trace it can see, and that is precisely the process worth knowing about.

Scheduled queries with differential results partly address this — run periodically, report what changed — and the gap between runs is a real blind spot. Anything shorter-lived than the interval is invisible.

This is the complementary relationship with auditd, which is worth being explicit about because the two are often presented as alternatives. auditd records events as they occur and produces volume; osquery answers questions cheaply and misses events between runs. Neither substitutes for the other, and a defensible setup uses both: audit rules narrowly on sensitive objects, osquery for state and inventory.

Query cost is the practical caveat. Some tables are expensive — anything walking the filesystem — and an aggressive schedule across a fleet is a self-inflicted load problem.

See also: auditd, Wazuh which can incorporate it, Checkmk for the monitoring side, and Linux administration in datacenters.