A virtual table is a queryable table that does not necessarily exist as a normal database object on disk. In osquery, it can represent live system state or parsed data from another source, including a SQLite file exposed through ATC. This abstraction lets defenders inspect structured endpoint data through a consistent SQL interface.
What a virtual table is
A virtual table is a queryable table that does not necessarily exist as a normal database object on disk. In osquery, it can represent live system state or parsed data from another source, including a SQLite file exposed through ATC. This makes endpoint data available as structured rows and columns without requiring the underlying source to be materialised as a conventional table.
How virtual tables work in practice
Virtual tables behave like ordinary SQL tables from the reader’s point of view, but their contents are produced on demand. A query may read from the operating system, a local file, a log source, or another structured input and present the results through the same interface. That abstraction is useful because it standardises access to different telemetry sources while keeping the query model familiar.
In osquery, this design lets defenders inspect endpoint artefacts with SQL syntax instead of learning a separate API for each data source. The table name becomes the stable contract, while the implementation behind it can vary from a live kernel-backed view to a parser over an imported SQLite source. The practical benefit is consistency: analysts can write one style of query across many types of endpoint data.
Why virtual tables matter for endpoint visibility
Virtual tables matter because they make ephemeral or scattered data easier to interrogate. Many endpoint facts are not naturally stored as relational records, yet defenders still need to search, filter, join and correlate them. By projecting those facts into a table shape, osquery supports fast investigation, repeatable hunting and more portable detections.
This model also reduces the friction of turning raw system state into actionable security data. Rather than copying data into a separate analysis store first, a virtual table can expose it directly for inspection. That is especially useful when the source is transient, locally scoped or more convenient to query in place than to ingest into another platform.
Common design traits and limitations
Virtual tables are an abstraction layer, not a guarantee about storage or freshness. Because the data may be generated at query time, the results can reflect the current state of the system rather than a historical snapshot. That makes them valuable for live visibility, but it also means query semantics depend on how the underlying source is implemented.
They can also differ in quality depending on the parser or provider behind them. A virtual table built from another source may inherit that source’s normalization choices, missing fields, or edge-case handling. For that reason, practitioners should treat the table interface as the user experience, not as proof that all data underneath it is complete, authoritative, or equally reliable.
Risk and Threat Considerations
Virtual tables improve visibility, but they also create an abstraction boundary that can hide how data is actually obtained, transformed, or delayed. If the underlying source is stale, incomplete, or overly permissive, analysts may draw incorrect conclusions from a table that looks consistent on the surface.
Failure mechanism: An attacker or operator error can exploit trust in the table layer while the backing data source is manipulated, filtered, or no longer representative of the endpoint state.
Impact: Investigations can miss malicious activity, detections can become unreliable, and teams may assume they are querying live truth when they are really querying a transformed view.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Virtual tables support structured inspection of endpoint data for audit and investigation. |
| CM-8 — System Component Inventory | Virtual tables expose live system state that depends on accurate asset and component visibility. | |
| Recommendation — Use AU-6 to review queryable endpoint data for anomalies and investigative evidence. Use CM-8 to maintain accurate endpoint inventory before relying on virtual-table queries. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Unauthorized Personnel, Connections, Devices, and Software | Virtual tables enable monitoring of endpoint state through consistent query-based visibility. |
| Recommendation — Use DE.CM-01 to continuously monitor endpoint conditions through structured queries. | ||
Practitioner Guidance
Why practitioners should care: The usefulness of a virtual table depends on understanding what it really represents. Query authors should know whether the table reflects live state, a parsed file, or another derived source so they can interpret results correctly and avoid overconfidence in a convenient interface.
What to watch for: Treat unusual gaps, surprising NULL values, and source-specific parsing behaviour as signals that the abstraction may not fully match the underlying system. The safest operational habit is to validate high-value queries against the source semantics, not just the table name.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org