osquery turns your fleet into a table you can select from

A vulnerability is published in a widely used library. The question from leadership is simple: are we affected, and on how many machines. The honest answer in most organisations takes two days, involves asking teams in a chat channel, and is wrong.

The same shape of question arrives during an audit, during an incident, and every time someone asks what is actually running on the laptops. It is an inventory question, and inventory is something almost every organisation believes it has and almost none does.

The idea is that the operating system is a database

osquery exposes the state of a machine as SQL tables. Running processes, listening ports, installed packages, users, scheduled tasks, kernel modules, browser extensions, disk encryption status, certificates, open sockets with the process that owns them.

Then you query it:

SELECT name, version FROM deb_packages WHERE name LIKE '%openssl%';

Run that across the fleet and you have the answer to the vulnerability question in the time it takes the results to come back. That is the whole pitch, and it is enough.

It runs on Linux, macOS and Windows with a largely shared schema, which matters because most fleets are mixed and most inventory tooling is not.

Two modes, and the scheduled one is where cost lives

Live queries are ad hoc: ask the fleet a question now, get answers back. This is the incident response and inventory use case, and it is the one that delivers value on day one.

Scheduled queries run on an interval on every host and ship results to your log pipeline, either as a full snapshot or as a differential showing what changed since the last run.

The second mode is where deployments go wrong. A query over the process table every thirty seconds across two thousand hosts produces an enormous volume of log data, which then costs money to ingest and store in exactly the way described in logs are the line that grows.

Discipline that works: schedule a small number of queries at sensible intervals, prefer differential results so you get changes rather than repeated state, keep fast-changing tables like processes on live query only unless you have a specific detection need, and measure the data volume per host before rolling out widely.

Also watch the resource cost on the endpoint. Some tables are expensive to materialise, and a badly chosen scheduled query is a performance complaint from every user at once.

What to actually query

Start with the questions you already get asked.

Inventory and compliance. Installed software and versions, operating system patch level, disk encryption enabled, screen lock configured, firewall status, antivirus running. This set answers most of an audit questionnaire and is the fastest return, feeding directly into the evidence discipline of automating SOC 2 evidence.

Configuration drift. Users with local administrator rights, SSH keys in home directories, sudoers entries, services enabled at boot, unexpected scheduled tasks.

Security-relevant state. Listening ports with their owning process, established connections to unexpected destinations, browser extensions, kernel modules, binaries in temporary directories, recently modified files in system paths.

The specific question of the week. This is where live queries earn their place, and it is why the tool stays useful after the initial project.

Public query packs exist and are a reasonable starting point, with the same caveat as everywhere else: they are written for a generic environment and will be noisy in yours.

Detection with it, carefully

osquery can support detection, and it is worth being honest about the fit.

It is good at state-based detection: a new local administrator account appeared, an unexpected service is now enabled, a binary showed up in a temporary directory, a persistence mechanism was added. Differential scheduled queries make these visible as changes rather than as a state you have to interpret.

It is poor at event-based detection. The polling model means a process that starts and exits between two runs is invisible, so it cannot replace a tool sitting at the syscall boundary. That is the job of the runtime detection described in Falco tells you what a container did, and the two are complementary rather than alternatives.

Route the results to your SIEM rather than building a parallel alerting system, which is the same argument as in detection as code. The rules belong where the correlation happens.

Deployment, and the part that is actually hard

The agent is straightforward. The management is not, which is why fleet management tooling exists around it.

You need a way to distribute configuration and query packs without editing files on hosts, a way to collect results centrally, a way to run a live query across the fleet from one place, and a way to know which hosts are not reporting. That last one matters most and is the easiest to neglect: a host that stopped reporting looks identical to a host with nothing to report.

Several open source and commercial fleet managers provide this. Whichever you use, treat the query pack as code in a repository with review, for the same reasons detection rules belong in one.

Roll out in stages. A pilot group, then a department, then the fleet, watching resource usage and data volume at each step.

The governance question you have to answer first

This tool can see a great deal about a user's machine, and deploying it without being explicit about that is a mistake that damages trust permanently.

Decide and publish what you collect and what you deliberately do not. Browser history, document contents, keystrokes and personal file names are examples of things you should not collect, and saying so clearly is worth more than any technical control. Restrict who can run live queries, log every query that is run and who ran it, and make that log reviewable.

In Europe this is not only a trust matter. Monitoring employee devices engages data protection obligations and, in many jurisdictions, employee representative consultation. Document the purpose and the legal basis before deployment rather than after, along the lines set out in GDPR as engineering controls.

The things people forget

• A host that stops reporting is a finding. Alert on it, or your coverage quietly degrades.
• Schema differs by platform. A query written for Linux may return nothing on macOS rather than failing loudly.
• Version differences matter. Tables and columns change between releases; pin the agent version and test packs against it.
• It runs with high privileges. The agent and its configuration channel are a valuable target, and the configuration is effectively remote code selection.
• Results are personal data in some jurisdictions. Retention applies.
• It answers questions, it does not fix anything. Pair it with a configuration management tool, or you will have excellent reports about problems nobody remediates.

What to do this week

Pick the last vulnerability advisory that mattered to you and write the query that would have answered "are we affected". Run it on ten machines. The time it takes you to get that answer today, compared with the time it would take with a deployed agent, is the entire business case, and it is usually measured in days against seconds. We scope this in the detection phase of a security engagement.