GQL Meets Threat Intelligence: Querying Provenance Graphs for Cyber Attack Investigation
gqlprovenancecyber-securitythreat-intelligenceproperty-graphsquery-languagesgraph-databasesincident-response
Loading…
Back openDesk Edu for a sovereign, open-source education — every vote counts.
Vote nowThe GQL deep-dive in our graph research corpus confirms what the raw numbers already hint at: Graph Query Language is the single fastest-accelerating research category in graphs in 2026 — up +235.7% year-over-year, with 119 papers published in the first eight months alone. Most coverage focuses on the standard's semantics, the theory of expressive power, and the benchmark wave behind natural-language-to-GQL. But buried inside that corpus is the topic with the most obvious real-world payoff: using property-graph query languages to query system provenance and trace cyberattacks.
This article zooms in on that thread — why provenance is a graph problem, how emerging GQL-style systems map onto it, and what it means for teams building security tooling today.
When a machine is compromised, the forensics story is rarely a single log line. An attacker leaves a trail of events: a process spawns, a file is opened, a network socket is created, a privilege changes. Each event links a subject to an object. Collect the events and the trail becomes a graph.
That is the definition of a provenance graph: nodes are system entities (processes, files, sockets, users, pipes), edges are the operations between them, and every edge carries timestamp, subject, and result properties. Unlike a flat audit log, a provenance graph preserves dependency and causality — exactly the structure an investigator needs to answer:
| Question | The query shape it needs |
|---|---|
| "How did this attacker get in?" | A path from the suspicious process back to an entry point |
| "What else did this binary touch?" | Aggregated outgoing edges from a node |
| "Is this a known attack chain?" | A subgraph pattern matching a threat signature |
| "What is the blast radius?" | Forward closure from the compromised node |
Classical tools query audit logs with regex and timestamp filters — which fails as soon as the trail spans multiple machines, containers, or hops. A graph query language is the natural home for these questions.
One of the most concrete applied results surfaced by the deep-dive is the use of a GQL-style language over audit-event provenance graphs. Several 2026 prototypes organise system audit events into provenance graphs and query them with graph query languages to trace attack steps. The pattern is consistent:
The practical merit of resting this on GQL rather than a bespoke tool is that GQL is a standard. The same query shape also runs over Neo4j/Cypher-flavoured engines today, and over formal GQL engines as they mature — so tooling written for one environment doesn't get rewritten for the next.
Here is a small stylised provenance subgraph a security investigator might reconstruct from an incident, plus the path-query that traces the attack.
// Nodes: process, file, socket entities
// Edge A->B means "A performed an operation on B"
//
// nginx
// ├──[READ]--> /etc/passwd (suspicious read)
// └──[CONNECT]--> 198.51.100.7:4444 (possible command-and-control beacon)
// Find every path from a web-facing process to a destination socket,
// following operations an attacker is known to chain:
MATCH p = (entry:Process)-[:READ|WRITE|EXEC|CONNECT]->*(sink:Socket)
WHERE entry.address = $webFront AND sink.port = 4444
RETURN p ORDER BY p;
That is the essence of every "how did it get here" investigation: multi-hop navigation over operations. What differs between systems is the schema and property shapes — which is exactly what the corpus's PG-Schema and graph-query-constraint research is built to formalise.
Note: dialects differ. Neo4j users write this with Cypher's
*andMATCH; emerging GQL engines expose the same reachability semantics with standard-compliant syntax. The semantic is where the value lives — which is precisely why the deep-dive flags expressiveness and RPQ-semantics research.
Beyond the prototype itself, the deep-dive surfaces several threads that directly matter to someone building provenance querying:
| Thread | What it says | Why it matters for incident response |
|---|---|---|
| Expressivity | Formal mapping of what the standard can and cannot express | Sets honest expectations for what to encode in application logic |
| RPQ semantics | Graph languages descend from regular path queries but differ in which walks they return | Two engines may answer the same path query differently — test yours |
| Compositionality | GQL/SQL-PGQ currently lack full compositionality | Constraining a whole attack-graph query can be hard |
| NL2GQL | Natural-language-to-GQL is now benchmarked (GQLBench, Adaptive Text2GQL) | Analysts can soon query provenance graphs with plain-language dialogue |
This is one thread of the story our graph query language research tells about 2026: the query-language layer is becoming a product surface again. For the broader 2026 context, see the GQL era: property-graph query languages, the GQL expressiveness gap, and the graph-powered OSINT framing this security angle pulls from. If you are running agents over a graph, the knowledge graphs as a context layer series connects the query layer to the agent stack.
Researched from the graph-research corpus (17,553 papers, 100% taxonomy saturation). Full appendix and sources live in the graph research repository; see the literature review and GQL investigation for the underlying evidence.