osquery in 2026 amounts to the most underused endpoint visibility tool in the typical enterprise. The enterprise deploys the EDR, the EDR catches the known threats, the EDR misses the unknown threats, the unknown threats sit on the endpoint unobserved. The osquery tables expose the endpoint state in a way the EDR cannot. The guide covers what the tables tell you, what they do not, and how to actually use them.
osquery exposes the endpoint as a relational database, with the tables covering the processes, the network connections, the kernel modules, the loaded libraries, the scheduled tasks, the browser extensions, the installed software, the logged in users, the system information. The tables run as the interface the analyst queries to answer the question ‘what runs as happening on this endpoint.’ The 2026 state of the osquery adoption amounts to a state where the tables sit available on the typical EDR (the Kolide, the Fleet, the Uptycs), the analyst does not query the tables, the analyst works around the tables.
The tables that matter
Three categories, in roughly that order of how much they tell you. The first runs as the process category, with the processes table showing every running process, with the path, the hash, the parent process, the command line, the user. The process category becomes the the category that answers the question ‘what ran on this endpoint.’ The second runs as the network category, with the process_open_sockets table showing every open socket, with the local address, the remote address, the state, the process. The network category. the the category that answers the question ‘who runs as this endpoint talking to.’ The third runs as the persistence category, with the launchd table on macOS, the scheduled_tasks table on Windows, the cron tables on Linux, the kernel_extensions table. The persistence category is what the category that answers the question ‘what will run on this endpoint after the reboot.’ The three categories together cover 80% of the security investigation work.
What the typical enterprise misses
Three things, in roughly that order of how often they come up. The first runs as the no query problem, where the tables sit in the EDR, the analyst does not query the tables, the analyst works from the alerts, the analyst misses the threats the alerts do not catch. The second runs as the no alert problem, where the tables expose the state, the EDR does not alert on the state changes, the analyst has to know what to look for, the analyst does not know what to look for. The third runs as the no context problem, where the table returns the raw data, the analyst does not have the context to interpret the raw data, the analyst cannot act on the data, the data sits unused. The three things together make the osquery tables effectively useless to the typical enterprise, even when the enterprise has paid for the EDR with the tables.
How to actually use it
Three moves if you are setting up the osquery practice. Build the query library, because the queries the analyst needs (the suspicious process, the unexpected network connection, the new persistence mechanism) get written once, get used many times, and the library amounts to the institutional knowledge the analyst needs. The query library without the institutional knowledge amounts to a list the analyst cannot extend. Build the alert rules, because the alert rules built on the osquery queries (the new process from the temp directory, the new network connection to the non corporate IP, the new persistence mechanism) run as the alerts the EDR does not produce. The alerts the EDR produces run as the known threats. The alerts the osquery produces run as the unknown threats. Train the analyst, because the analyst who does not know the osquery schema cannot use the tables, the analyst who knows the schema can answer the questions the alerts cannot. The enterprise that builds the library, builds the alert rules, and trains the analyst stands as the enterprise that gets the security value from the osquery tables.
The bottom line
osquery in 2026 amounts to the most underused endpoint visibility tool in the typical enterprise. The three categories (process, network, persistence) cover 80% of the security investigation work. The three mistakes (no query, no alert, no context) make the tables useless. The enterprise that builds the library, builds the alert rules, and trains the analyst stands as the enterprise that gets the value from the osquery tables.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
