Osquery for Compliance: Auditing CIS Benchmarks with SQL

Osquery compliance is not about passing an audit. It is about proving your controls hold on every day of the year, not just the one day an auditor is watching.

Most compliance tooling answers the wrong question. It produces a snapshot that says the fleet was configured correctly on the day the report ran. Auditors accept it, everyone moves on, and the configuration quietly drifts for the next twelve months. The problem was never proving compliance on audit day. The problem is the other 364 days, when a firewall rule gets loosened for a deploy and never restored, or a benchmark setting gets reverted by a bad image.

Osquery is a good fit here for one reason: it reads the actual state of the host as SQL, on a schedule, forever. A CIS benchmark item stops being a checklist entry and becomes a query that either returns a compliant row or it does not. This piece covers what osquery can actually check against CIS benchmarks, what the queries look like, and where the honest limits are.

What can osquery check against CIS benchmarks?

The Center for Internet Security publishes hardening benchmarks for operating systems, cloud platforms, and applications, and a large share of the operating system items map to a state you can read on the host. Osquery exposes that state through virtual tables, so a benchmark control becomes a query with an expected result.

The categories that translate well: filesystem mount options, kernel and network parameters, account and password policy, installed and prohibited packages, running services, and file permissions on sensitive paths. These are the bulk of a Linux CIS benchmark. What does not translate as cleanly are the items that require reading a specific config file's semantics or judging intent, which is a limit worth naming up front rather than pretending a query covers everything. For the full table surface you can draw on, our osquery tables reference is the place to start.

What do CIS compliance queries look like?

Start with filesystem mount options, a staple of every Linux benchmark. CIS wants temporary directories mounted with restrictions so an attacker cannot execute or escalate from them. The mounts table reads the live mount state:

SELECT path, type, flags
FROM mounts
WHERE path = '/tmp'
  AND flags NOT LIKE '%nosuid%';

A returned row is a failed control. An empty result is a pass. That inversion is the whole trick of compliance querying: you write the query to find violations, so no news is good news. Network parameters work the same way through the system_controls table, which reads live sysctl values. CIS wants IP forwarding off on a host that is not a router:

SELECT name, current_value
FROM system_controls
WHERE name = 'net.ipv4.ip_forward'
  AND current_value != '0';

Account policy is next. A benchmark item every framework shares is that only the root account should hold UID 0. One query proves it across the fleet:

SELECT username, uid, description
FROM users
WHERE uid = 0
  AND username != 'root';

Prohibited software rounds it out. If your benchmark forbids a service like telnet, the package tables answer instantly. This is the same inventory precision we covered in osquery vulnerability detection, pointed at policy instead of CVEs:

SELECT name, version
FROM deb_packages
WHERE name IN ('telnet', 'rsh-server', 'xinetd');

Windows benchmarks lean on the registry, and osquery reads it as a table too. A CIS control might require that remote desktop connections enforce network level authentication. The registry table checks the exact key:

SELECT path, data
FROM registry
WHERE key = 'HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Terminal Server\\WinStations\\RDP-Tcp'
  AND name = 'UserAuthentication'
  AND data != '1';

None of these is complicated on its own. The power is that the same handful of patterns, mount flags, sysctl values, account state, package presence, and registry keys, cover a large fraction of a benchmark, and every one of them runs fleet wide in seconds. That last part is what changes the economics. A control you can check on one host by hand is a control you can check on fifty thousand hosts with the same query and no extra effort. The marginal cost of proving a control across the whole estate drops to almost nothing, which is the property that makes continuous compliance affordable instead of aspirational.

Why the it-compliance pack is not a compliance program

Osquery ships with a compliance oriented query pack, and a common mistake is to assign it to every host and declare the box checked. That is not what it is. A pack is a set of queries. It has no idea which benchmark applies to which system, what your accepted exceptions are, or whether a returned row is a real violation or an approved deviation. We went deep on how packs load and where they stop in the osquery query packs guide.

A compliance program needs three things a pack does not provide. It needs scoping, so the right controls run against the right systems. It needs exception handling, so a documented, risk accepted deviation does not reappear as a failure every scan. And it needs evidence retention, so you can show an auditor the control was in place across the whole period, not just today. The pack gives you the queries. You still have to build the program around them, which is exactly the part teams underestimate.

Continuous evidence beats a snapshot

This is the argument that actually matters. An annual audit samples one day out of 365. Configuration drift happens on the other 364, and drift is where breaches live. A control that was set correctly in January and reverted in March is a failure your annual audit will never see, because the audit was in January.

Run the math on effort, too. Doing CIS checks by hand, an engineer might spend fifteen minutes per host confirming a dozen settings. Across 500 servers that is 125 hours, once, for a snapshot that is stale the moment it finishes. The same checks as scheduled osquery queries run continuously across all 500 hosts for effectively zero marginal labor, and they alert the day a control drifts. This is the same shift from periodic scan to continuous state that we made the case for in running osquery at fleet scale, applied to compliance instead of security. The CIS benchmarks define the target state; osquery is one way to prove you are holding it. For the collection mechanics, the official osquery configuration docs cover scheduling and logging.

A practical approach

Build compliance monitoring the way you would build detection:

• Map the benchmark. Take the CIS items for each platform and identify which map to an osquery table. Accept that some will not, and cover those elsewhere.
• Write each control as a query that returns violations, so an empty result is a pass and any row is an exception to review.
• Scope the queries to the systems the control applies to, using packs and platform filters rather than one blanket assignment.
• Schedule them and retain the logs. The retained history is your evidence that the control held across the audit period, not just on audit day.
• Handle exceptions explicitly. A documented, approved deviation should be suppressed by rule, not silently ignored or re-triaged every run.

The first four steps are mechanical. The fifth, separating an approved exception from a real drift event at scale, is judgment work, and it is where compliance dashboards turn into noise. That is the gap Artemes AI is built to close: pairing deep endpoint context with AI driven analysis that reads the real system state to decide which deviations are genuine control failures and which are known, accepted variance, so the evidence you hand an auditor is signal rather than a spreadsheet of unresolved rows. Osquery proves the state. Something still has to interpret it against your policy.

Frequently asked questions

Does osquery make my systems CIS compliant?

No. Osquery measures whether a system meets a control; it does not change the configuration. It is a monitoring and evidence tool, not a hardening tool. You still apply the benchmark settings through your configuration management, then use osquery to prove and continuously verify they stay applied.

Which frameworks can osquery help with beyond CIS?

The same state reading approach supports PCI DSS, SOC 2, and internal hardening standards. Any requirement that reduces to a checkable host setting, such as encryption on, a service disabled, or a package absent, can be written as an osquery query and monitored continuously.

What compliance checks can osquery not do?

Items that depend on the semantics of a specific config file, on process or organizational controls, or on human judgment do not reduce to a table read. Osquery covers the measurable technical state. Policy, training, and documentation controls sit outside it.

How is this different from a vulnerability scan?

A vulnerability scan asks whether software has known flaws. A compliance check asks whether configuration matches a defined standard. Both read host state, but they answer different questions, and a system can be fully patched and still fail a benchmark, or hardened and still carry a vulnerable package.

The takeaway

Treat CIS compliance as a monitoring problem, not an audit event. Map each benchmark item to a query that returns violations, scope it to the systems it applies to, schedule it, and keep the logs as evidence that the control held all year. Osquery makes the technical portion of a benchmark continuously verifiable for almost no marginal cost, which is a real upgrade over a once a year snapshot. The work that remains is deciding what a returned row actually means. Build for that, and your next audit becomes a query you already ran a thousand times, not a fire drill.