---
title: Security Knowledge Graph Overview
url: https://www.emergentmind.com/topics/security-knowledge-graph
type: topic
---

# Security Knowledge Graph Overview

A security knowledge graph is a structured graph representation of cybersecurity knowledge in which entities such as products, vulnerabilities, weaknesses, malware, indicators, attackers, techniques, hosts, tools, alerts, tickets, or program artifacts are connected by typed relations so that the resulting structure can be queried, analyzed, and, in some settings, used for reasoning or prediction. Across the literature, the term encompasses several closely related artifacts: threat-intelligence graphs built from unstructured reports, vulnerability graphs that unify databases such as CPE, CVE, and CWE, context-rich operational graphs for blue-team defense, program knowledge graphs for software and hardware security, and domain-specific ontologies such as social engineering. A common premise is that cybersecurity knowledge is abundant but fragmented across heterogeneous sources and formats, and that graph structure provides a way to integrate this information into a form suitable for inference, prediction, explanation, and decision support [2102.05583] [2305.00632] [2606.21059].

## 1. Conceptual scope and defining characteristics

Security knowledge graphs are not a single schema or storage model. In the literature, they appear as RDF triple graphs grounded in malware ontologies, property graphs implemented in Neo4j, multi-modal graphs linking documents to latent topics and named entities, dual-layer static-dynamic graphs for incident response, and task-specific graphs for domains such as social engineering, container security configuration, finite-state-machine security, or program vulnerability discovery [2102.05583] [2403.16222] [2606.21059].

A recurring distinction is between low-level observables and higher-level threat knowledge. Earlier OSCTI platforms were described as focusing mainly on isolated Indicators of Compromise, whereas knowledge-graph approaches emphasize entities and relations at multiple levels, including malware, threat actors, vulnerabilities, techniques, tools, attack methods, impacts, and mitigation knowledge. This broader relational scope is presented as essential for understanding “the complete threat scenario” rather than only enumerating artifacts [2101.07769].

The literature also distinguishes between storing facts and supporting downstream reasoning. In malware threat intelligence, RDF triples are chosen not merely as a database representation but because linked facts can support reasoning and “discover new threat intelligence” through inferred or previously overlooked connections [2102.05583]. In vulnerability intelligence, a threat knowledge graph is explicitly defined as \( (E, R, T) \), where \(E\) is the set of entities, \(R\) the set of relations, and \(T\) the set of triples \(\langle h,r,t \rangle\), and is used to predict missing or not-yet-disclosed CPE–CVE and CVE–CWE associations [2305.00632]. In blue-team settings, the graph is treated as a grounding substrate for LLM reasoning, with paths rather than flat documents serving as the unit of retrieval and explanation [2606.21059].

A plausible implication is that “security knowledge graph” functions as an umbrella term spanning at least three roles: a representation layer for integrating heterogeneous cyber knowledge, a reasoning substrate for prediction or graph analytics, and an operational memory for analyst- or LLM-facing security workflows.

## 2. Graph models, ontologies, and schema design

Schema design in security knowledge graphs is typically ontology-guided, but the degree of formalization varies widely. TINKER, a malware threat-intelligence graph, reuses open-source malware ontologies, especially those of Rastogi et al. (2020) and Swimmer (2008), and is built from classes and properties such as **Malware**, **Vulnerability**, **Indicator**, **Attacker**, **Host**, and **Software**, with properties including **authored**, **usesHost**, **runsSoftware**, **hasReleaseYear**, and **hasVersion** [2102.05583]. The authors emphasize competency questions as the requirements specification for the graph, including missing-information discovery, grouping by similarity, impact analysis, and prediction of future course of action.

Other systems derive schema from security standards. RelExt uses a cybersecurity knowledge graph schema based on **UCO 1.0**, updated using **STIX 2.0** relationships and classes and referred to as **UCO 2.0**. Its core classes include **Software**, **Malware**, **Indicator**, **Vulnerability**, **Course-of-action**, **Tool**, **Attack-pattern**, and **Campaign**, with relations such as **hasProduct**, **hasVulnerability**, **mitigates**, **uses**, **indicates**, **attributed-to**, **related-to**, and **located-at** [1905.02497]. CTiKG similarly aligns extraction to STIX 2.1 concepts, using 19 entity types in DNRTI-AUG-STIX2 and a typed relation ontology including **affiliatedWith**, **associatedWith**, **contains**, **hasAttackLocation**, **hasAttackTime**, **hasLocation**, **hasVulnerability**, **identifies**, **identifiedBy**, **monitors**, **monitoredBy**, **targets**, **targetedBy**, **uses**, and **usedBy** [2605.15904].

In vulnerability-centric graphs, the ontology is narrower but more explicit. The CWE–CVE–CPE threat knowledge graph represents CPE entries, CVE entries, CWE entries, CWE views, and CWE categories, plus selected attribute nodes. Relations include **HasPart**, **HasVendor**, **HasProduct**, **HasTechnology**, **LikelihoodOfExploit**, **MatchingCVE**, **MatchingCWE**, **ChildOf**, **CanPreceed**, **PeerOf**, **MemberOfView**, and **MemberOfCategory** [2305.00632]. TRACE generalizes this idea into a multidimensional ontology spanning vulnerability, attack, and defense, ultimately reporting **56 node types** and **112 edge types** in a graph with **4,741,428 nodes** and **24,980,064 edges** [2602.11211].

Some domain-specific works construct specialized ontologies rather than broad cyber schemas. The social-engineering ontology defines **11 concepts of core entities** and **22 kinds of relations**, including **Attacker**, **Attack Motivation**, **Attack Goal**, **Social Engineering Information**, **Attack Strategy**, **Attack Method**, **Attack Target / Victim**, **Attack Medium / Social Interaction**, **Human Vulnerability**, **Effect Mechanism**, and **Attack Consequence** [2106.01157]. SecFSM defines a vulnerability-centric FSM Security Knowledge Graph whose nodes include **Vulnerability**, **stage**, **type**, **Check**, **Consequence**, **GoodExample**, **BadExample**, **suggestions**, **manner**, **confirm**, **confirm_positive**, **confirm_negative**, **positive_example**, and **negative_example** [2508.12910].

This diversity reflects a persistent design tension. Broad schemas improve interoperability across sources, while task-specific schemas preserve the structural distinctions that generic text similarity or generic entity taxonomies often miss. The hardware-security literature makes this point explicitly: FSM vulnerabilities are tied to state transition and state information, so “security knowledge cannot be matched by semantic information” alone [2508.12910].

## 3. Construction pipelines: from text, databases, telemetry, and code

Security knowledge graphs are constructed from both structured and unstructured inputs, and the construction methodology strongly depends on source type.

For unstructured CTI and threat reports, early pipelines are typically annotation-centric. TINKER begins with **83 threat reports** published between **2006 and 2021**, converted from **PDF or HTML into text**, tokenized, separated into sentences, and loaded into the **Brat annotation tool**. The resulting graph contains approximately **3000 RDF triples**, produced mainly through manual named entity recognition and relation extraction; the reports were “manually annotated by the authors and reviewed by a security expert” [2102.05583]. The paper explicitly notes that generic NER tools such as spaCy, Stanford, and Flair are limited on cybersecurity text, although Flair produced the most accurate results for ontology-mapped classes. Generic entity linkers such as DBpedia Spotlight also struggle with contextual references such as “Aurora” after “Operation Aurora” [2102.05583].

RelExt addresses the graph-population step after NER. Its pipeline ingests cybersecurity blogs, technical reports, NVD/CVE feeds, Microsoft and Adobe bulletins, and STIX/TAXII-derived triples; applies a cybersecurity-specific NER; generates candidate entity pairs; filters them by schema and a **35-word window threshold**; represents entities with **200-dimensional Word2Vec** embeddings trained on cybersecurity text; and classifies relations using a feed-forward neural network with hidden layers of **200**, **100**, and **50** neurons [1905.02497]. This is a graph-enrichment approach rather than graph completion from topology alone.

More recent CTI graph-construction pipelines strengthen the extraction stage with domain-adapted language models and ontology constraints. CTiKG is a three-phase pipeline: data collection and processing from CTI sources such as APT repositories, MITRE ATT&CK, and TrendMicro; entity-relation extraction using **SecureBERT\(^+\)-BiGRU-CRF** for NER and **SecureBERT\(^+\)-BiGRU-TDD** for RE; and graph construction in Neo4j [2605.15904]. The ontology is used twice: to label valid entity pairs during dataset creation and to validate or correct relation predictions at inference time. On DNRTI-AUG-STIX2, the NER model achieves **Precision 0.93, Recall 0.94, F1 0.93**, while the RE model reaches **Precision 0.98, Recall 0.98, F1 0.98** [2605.15904].

GRID moves from sentence- or pair-level extraction to full article-to-graph generation. It first creates traceable article-graph supervision through graph extraction plus KG-conditioned article revision, then converts document-to-graph learning into a task bank of four-option multi-select questions and triple-level regex targets. On **249 CTI articles** from **GRID, CASIE, CTINexus, MalKG, and SecureNLP**, the ontology-guided Task-bank Reward model reaches **84.62%** source-averaged precision, **64.91%** source-averaged recall, and **68.53%** Avg F1 [2605.16714]. The paper argues that offline task-bank rewards are more stable and cheaper than repeatedly using an online LLM judge over full graph outputs.

Structured-source pipelines are different. The CWE–CVE–CPE threat knowledge graph is built from official snapshots of CPE, CVE, and CWE, with deterministic identifier normalization, version-aware CPE merging, removal of unconnected entries, and subsequent knowledge graph embedding training [2305.00632]. TRACE combines **24 structured databases** with **3 categories of unstructured data**—APT reports, academic papers, and repair notices—using timestamp-driven acquisition, regex extraction for canonical identifiers such as CVEs, LLM-assisted extraction for semantically complex entities and triples, sentence-transformer candidate generation, and LLM-based final alignment with threshold \(\theta = 0.9\) [2602.11211]. MultiKG constructs source-specific graphs from **CTI reports, audit/provenance logs, and static attack code**, then performs same-source aggregation and cross-source fusion keyed by ATT&CK technique number, node type, hierarchy, and content similarity [2411.08359].

A separate line of work grounds security graphs in software or hardware artifacts. The Program Knowledge Graph integrates CVE/CWE knowledge with **call graph** information from code, linking weakness/event nodes to procedure calls in Neo4j and using Cypher to detect weakness patterns such as **CWE-415 double free**. It identifies **14 out of 15** weaknesses across **8** CWE categories on **15** C/C++ examples, while explicitly noting that **CWE-401** could not be found because **data flow graphs** are required and call graphs alone are insufficient [2312.04818]. SecFSM similarly constructs a transient FSM security state transition graph from requirements before querying a persistent FSM security knowledge graph [2508.12910].

## 4. Learning, reasoning, and graph-based prediction

Once constructed, security knowledge graphs are used for several classes of downstream reasoning: link prediction, anomaly scoring, logical/path reasoning, and query answering.

In vulnerability intelligence, graph completion is central. The CWE–CVE–CPE graph uses TransE, DistMult, and ComplEx to rank candidate CPEs or CWEs for a given CVE. On the **August 4, 2021** graph, TransE performs best, achieving **MRR 0.424, MR 1643, Hits@10 0.573** for CVE\(\rightarrow\)CPE and **MRR 0.445, MR 13, Hits@10 0.731** for CVE\(\rightarrow\)CWE in closed-world evaluation [2305.00632]. Open-world validation, based on links added after the training snapshot, shows lower but still meaningful performance; for Aug 2021–Mar 2022, CVE\(\rightarrow\)CPE reaches **MRR 0.159, MR 2068, Hits@10 0.276**, and CVE\(\rightarrow\)CWE reaches **MRR 0.143, MR 38, Hits@10 0.358** [2305.00632]. The paper’s optimization results are also notable: pruning unconnected nodes improves embedding quality, and removing old entries improves future-link prediction even when closed-world metrics do not improve materially.

In context-aware monitoring, the graph itself becomes the anomaly model. The industrial security-monitoring paper represents the KG as a binary tensor
\[
\mathbf{X} \in \{0,1\}^{n \times m \times n},
\]
and uses a RESCAL-style energy-based model where
\[
p(\mathbf{X}) = \frac{1}{Z} e^{-E(\mathbf{X})}, \quad
E(\mathbf{X}) = - \sum_{s,p,o} X_{s,p,o}\,\theta_{s,p,o}.
\]
At runtime, each event produces multiple triples; low-probability triples under \(p_{s,p,o} = \sigma(\theta_{s,p,o})\) are treated as suspicious. The paper’s emphasis is not on benchmark ROC curves but on “intuitively well-calibrated and interpretable alerts” across scenarios such as variable access, HTTPS access, SSH access, credential use, and network scan [2105.08741].

KnowGraph occupies an adjacent space between anomaly detection and knowledge-graph reasoning. It combines a main graph-learning model with multiple specialized knowledge models and a reasoning component based on probabilistic graphical models and weighted first-order logic formulas. On LANL, it reaches **AUC 0.9999** and **AP 0.8886** in the transductive setting, compared with **AUC 0.9946, AP 0.0433** for Euler and **AUC 0.9995, AP 0.3249** for EncG; in the inductive setting it reaches **AUC 0.9112, AP 0.0852** [2410.08390]. On eBay, where the graph is explicitly described as a heterogeneous knowledge graph of users, items, and transactions, KnowGraph improves inductive performance from **AUC 0.498, AP 0.0001** for DGI to **AUC 0.609, AP 0.121**, and **KnowGraph+PCS** further improves to **AUC 0.649, AP 0.167** [2410.08390]. This suggests that logical constraints and semantic auxiliary tasks can stabilize graph-based detection under distribution shift.

In LLM-grounded blue-team reasoning, the graph becomes both context memory and retrieval substrate. DEFENGRAPH uses a dual-layer **Static Knowledge Graph (SKG)** and **Dynamic Knowledge Graph (DKG)**, with dynamic nodes carrying timestamps \(t_i\) and temporal weighting
\[
w_t = \exp(-\alpha |t_i - t_q|).
\]
Given a Wazuh alert \(W_q\), retrieval is performed over graph triples \(T_q = \langle e_q, r_q, e'_q \rangle\) and \(T_g = \langle e_g, r_g, e'_g \rangle\), with semantic matching and path propagation, followed by LLM-based contextual filtering and reasoning re-ranking [2606.21059]. On GPT-4o, moving from static DefenGraph to full DefenGraph raises reasoning recall from **61.45%** to **73.49%** and ticket-action recall from **52.17%** to **72.46%**, with precision increasing from **24.49%** to **29.24%** [2606.21059]. The same paper shows that the full dual-layer graph is stronger than either layer alone, and that graph-based retrieval plus contextual filtering matters as much as the graph content itself.

The literature also includes explicit concern about adversarial manipulation of graph reasoning. The study on knowledge graph reasoning security formalizes conjunctive-query answering and proposes ROAR, with knowledge-poisoning and query-misguiding variants that can steer reasoning outputs under partial knowledge. In cyber threat hunting, ROAR-CO reaches **MRR 0.61, HIT@5 0.71** on target queries in a backdoor setting, and in targeted attacks reduces threat-hunting vulnerability-query performance from **HIT@5 0.98** to **0.06** [2305.02383]. This paper directly challenges the assumption that a structured graph plus learned reasoning is intrinsically trustworthy.

## 5. Application domains

Security knowledge graphs are applied across a broad range of cybersecurity tasks, and the application space is one of the clearest indications that the term denotes a family of systems rather than a single architecture.

Threat intelligence and malware analysis are the earliest and most explicit domain. TINKER demonstrates graph construction from malware reports, including triples such as **(DUSTMAN, similarTo, ZeroCleare)** and **(DUSTMAN, involves, dustman.exe)**, while figure-based examples include indicator-to-malware relations and malware-family similarity links [2102.05583]. SecurityKG similarly provides an end-to-end OSCTI gathering and management system with **40+ crawlers**, throughput of **350+ reports per minute on a single deployed host**, and **120K+ OSCTI reports collected**, integrating malware, vulnerabilities, threat actors, techniques, tools, software, vendors, and IOCs into a graph exposed through React, Elasticsearch, and Neo4j [2101.07769].

Vulnerability intelligence is another major use case. The CWE–CVE–CPE graph is explicitly designed to uncover future product-vulnerability and vulnerability-weakness associations [2305.00632]. TRACE extends this into a much broader CKG for threat hunting, risk analysis, attack analysis, and vulnerability management, reporting **1.82\times** more nodes and **1.79\times** more edges than the previous largest CKG and entity-extraction **precision 86.08%**, **recall 76.92%**, **F1 81.24%** [2602.11211].

Operational defense and monitoring form a third cluster. The industrial-monitoring KG supports context-aware anomaly scoring in OT/IT-converged environments [2105.08741]. DEFENGRAPH integrates SIEM alerts, system topology, attacker behaviors, prior defensive actions, tickets, and logs in cyber-range exercises to support explainable mitigation suggestions [2606.21059]. KnowGraph applies graph reasoning and domain knowledge to fraud/collusion detection and enterprise intrusion detection [2410.08390].

Security knowledge graphs are also built around attack procedures and telemetry rather than only reports. MultiKG uses **1,015 attack procedures**, covering **282 attack techniques** from Atomic Red Team, plus **9,006 CTI procedure descriptions** from MITRE ATT&CK, and fuses CTI, logs, and static code into technique-level attack graphs. On manually merged cross-source ground truth, MultiKG reaches approximately **node precision 0.922, recall 1.000, F1 0.959** and **edge precision 0.919, recall 1.000, F1 0.958**, whereas AttacKG achieves **node precision 0.588, recall 0.508, F1 0.545** and **edge precision 0.293, recall 0.509, F1 0.372** [2411.08359]. This line of work treats the graph as a structured model of attack execution rather than only as a repository of CTI facts.

Program and hardware security introduce graphs at the code and control-logic level. The Program Knowledge Graph links CVE/CWE knowledge to fine-grained call-graph information to uncover vulnerabilities in actual implementations [2312.04818]. SecFSM uses its FSM Security Knowledge Graph to guide LLM-based Verilog generation and achieves security pass rates of **16/25**, **20/25**, and **21/25** on GPT-4o, Claude 3.5, and DeepSeek-R1 respectively, outperforming both plain generation and generic RAG baselines [2508.12910].

The domain can also be highly specialized. The social-engineering ontology and graph encode **15 social engineering attack incidents and scenarios**, supporting seven application examples, including top-ranked threat elements, potential threats to victims, potential targets for attackers, attack-path discovery, and same-origin attack analysis [2106.01157]. The same paper reports that the top three exploited human vulnerabilities are **credulity**, **helpfulness**, and **conformity**, while the top three attack media are **email**, **website**, and **telephone** [2106.01157].

A broader implication is that security knowledge graphs are increasingly used not only to describe known threats, but also to bridge between data modalities: reports, databases, logs, code, architecture, tickets, and social/behavioral factors.

## 6. Limitations, misconceptions, and open problems

The literature repeatedly emphasizes that current security knowledge graphs remain incomplete, task-dependent, and often labor-intensive.

A common misconception is that standards such as **STIX** and **TAXII** solve the full knowledge-graph problem. The malware-KG literature explicitly argues that these standards are useful for sharing threat intelligence but do not solve extraction and standardization from the large volume of free-text reporting on the web [2102.05583]. A related misconception is that generic knowledge graphs such as Freebase, Google’s Knowledge Graph, WordNet, or generic Linked Open Data provide sufficient cybersecurity coverage; multiple papers reject this, citing missing domain-specific entities and relations [2102.05583] [2305.00632].

Extraction quality remains a core bottleneck. Early systems such as TINKER rely heavily on manual annotation and provide expert review but no inter-annotator agreement metrics [2102.05583]. RelExt reports strong classification accuracy—**96.21%** on the **80-20 split**, **91.88%** on **70-30**, and **91.34%** on **66-34**—but its classifier uses only entity embeddings plus heuristics rather than full sentence modeling, and the paper does not compare against stronger contextual baselines [1905.02497]. CTiKG improves extraction substantially, yet its limitations section explicitly leaves graph construction and downstream analysis “for future work” and does not address co-reference resolution, event extraction, multilingual CTI, or web-scale ingestion [2605.15904].

Graph evaluation is often proof-of-concept rather than end-task rigorous. TINKER provides no quantitative KG-quality metrics or downstream benchmark, only expert-reviewed annotations and illustrative examples [2102.05583]. SecurityKG is a systems/demo paper with scale numbers but no extraction precision/recall or usability study [2101.07769]. MultiKG provides strong manual-ground-truth comparisons, yet its fusion algorithms remain heuristic and do not specify exact similarity metrics or thresholds [2411.08359]. TRACE demonstrates scale and extraction quality, but still contains **124,866 Isolated Nodes** and acknowledges that hallucinations remain unavoidable, giving a concrete error example in which “tool” is misclassified as “technique” [2602.11211].

Temporal maintenance is another open problem. Threat intelligence “can quickly get stale” if not continuously updated [2102.05583]. TRACE addresses this with incremental crawling and timestamp-aware acquisition [2602.11211], and DEFENGRAPH addresses it through a DKG with temporal weighting [2606.21059], but most other systems are effectively static snapshots. Practical deployment therefore requires not just graph construction but also update, pruning, provenance, and possibly deletion policies—details rarely specified in the papers.

Security of the graph itself is a distinct concern. The KGR-security paper shows that a security KG can remain syntactically valid while its learned reasoning layer is steered toward attacker-desired answers through plausible poisoning facts or query manipulation [2305.02383]. This suggests that provenance, representational consistency checks, selective-failure monitoring, and layered defenses are necessary if KGs are used in high-stakes domains such as threat hunting or incident response.

Finally, the field contains an unresolved design tension between breadth and depth. Broad graphs such as TRACE maximize coverage across vulnerability, attack, and defense [2602.11211]. Narrower graphs such as the social-engineering ontology, Program Knowledge Graph, or FSM Security Knowledge Graph model fewer domains but capture task-specific semantics that generic pipelines may miss [2106.01157] [2312.04818] [2508.12910]. This suggests that future work will likely continue along both tracks: expansive cyber-domain graphs for integration and specialized subgraphs for domains where security semantics are strongly structural, temporal, or socio-technical.

Source: https://www.emergentmind.com/topics/security-knowledge-graph