A Queryable Graph-Based Security Analysis Framework for O-RAN

• O-RAN security knowledge is fragmented, and stakeholders must manually cross-reference specifications, vendor whitepapers, and studies to connect theoretical threats with software, vulnerabilities, and defenses.The process is described as error-prone and static, hindering a holistic view of the threat landscape.Source: §1 · p. 1
• The framework turns static documentation into a queryable graph with over 350 nodes and 1,250 relationships, unifying threats, empirical evidence, software, and known weaknesses.Queries can retrieve prioritized high-risk threats and empirical defenses.Source: §1 · pp. 1–2
• The semi-automated extraction pipeline reduces graph-maintenance effort from about 15 person-hours to 65 minutes while preserving high accuracy for static content extraction.Source: §1 · p. 2
• O-DU carries dozens of specification-level threats but little empirical coverage; memory safety accounts for 11 of 21 CWE occurrences, and fuzzing uncovered 18 of 20 CVEs attributed to research papers.These findings are within the curated corpus and analyzed CVEs described in the paper.Source: §1 · p. 2
• The open-source artifact includes the graph model, interactive demo, codebase, Cypher queries, GUI, prompts, curated CSVs, and instructions.Source: §1 · p. 2

2. O-RAN Overview

• Decoupling hardware and software at different levels enables a vendor-neutral ecosystem and fosters collaboration and competition among equipment suppliers and software developers.Source: §2 · p. 2

2.1. O-RAN Components and Interfaces

• O-RAN components span management, radio control, processing, and cloud infrastructure, while interfaces connect functions such as the SMO, RICs, O-DU, and O-RU.The overview also describes xApps and rApps hosted on the Near-RT and Non-RT RICs, respectively.Source: §2.1 · pp. 2–3

2.2. O-RAN Security Ecosystem

• Specifications, industry reports, and academic studies address different parts of O-RAN security, leaving a fragmented landscape and a need for systematic analysis.The O-RAN Threat Model catalogs risks across the SMO, RICs, and open interfaces; the security focus group became WG11 in 2022.Source: §2.2 · p. 3

3.1. Rationale

• Static surveys hinder tracing connections between threats, components, and affected software, while a graph can unify these sources for dynamic exploration.The authors frame the graph as a metaanalysis tool spanning otherwise isolated O-RAN security contexts.Source: §3.1 · p. 4

3.2. Our Methodology

• The graph combines deterministic parsing of structured specifications with LLM-assisted extraction for unstructured literature, under human-in-the-loop supervision.The resulting database contains over 350 nodes and more than 1,250 relationships.Source: §3.2 · p. 4, §3.2.1 · p. 4

3.2.1. Data Sources and Ontology.

• The ontology defines Components, Interfaces, Threats, Attacks, Defenses, and Software, drawing data from specifications, empirical literature, implementations, and vulnerability databases.The literature set includes only works demonstrating proof-of-concepts or experimental validation.Source: §3.2.1 · p. 4

3.2.2. Hybrid Extraction Pipeline.

• For structured threat-model tables, deterministic parsing cut extraction time from 5 hours manually to under 2 minutes; LLM processing curated 35 papers in 65 minutes versus about 15 person-hours manually.The LLM module uses schema-first prompts and validates structured outputs before CSV conversion.Source: §3.2.2 · p. 5

3.2.3. Maintenance and Reproducibility.

• A GUI supports PDF uploads, document-type selection, append or rebuild runs, and versioned logs; updating specification threats took about 7 minutes with the guided pipeline, excluding LLM processing.Earlier specification revisions were validated using strict prompts and a schema validator, with outputs consistent with the graph schema.Source: §3.2.3 · pp. 5–6
• Users can explore the graph with queries or natural-language questions translated into schema-aligned graph queries, with query results reviewed to detect unsupported outputs.The workflow can iteratively generate queries, execute them against a local Neo4j service, and refine results.Source: §3.2.4 · p. 6, §3.2.3 · p. 6

3.2.4. A Queryable Security Database.

• A query identifies components without empirical attacks, defenses, preventive measures, or CVEs, and returns software implementations of those components.The listing describes this as surfacing under-scrutinized O-RAN components.Source: §3.2.4 · p. 6

4.1. Empirical Attack and Defense Landscape

• Research clusters around intelligent control, while open interfaces and infrastructure form other domains; the infrastructure remains significantly under-studied.The paper organizes the landscape into RICs and xApps, open interfaces, and O-DU/O-CU infrastructure.Source: §4.1 · p. 6
• The O-DU and O-RU have few empirical studies, and only one dataset work scrutinizes the O-DU, O-CU, and F1 comprehensively.The O-DU processes real-time radio signals, which the paper identifies as vital for network availability.Source: §4.1 · p. 7

4.2. Identified Coverage and Gaps

• Threats concentrate on the Near-RT RIC, while prevention and detection mechanisms focus there and address interfaces only sporadically.Figures 8 and 9 map threats to components or interfaces and show prevention and detection mechanisms, respectively.Source: Figure 8 · p. 7, §4.2 · p. 7, Figure 9 · p. 8
• SMO, Non-RT RIC, and O-Cloud have virtually no empirical security research despite high theoretical risk scores, while E1 and F1 remain literature blind spots.The paper attributes infrastructure gaps partly to the cost and integration complexity of replicating realistic, vendor-compatible deployments; E1/F1 coverage may reflect their 3GPP CU/DU scope.Source: §4.2 · pp. 7–8

4.3. Accuracy of LLM-based Automation

• The evaluation separates LLM outputs into comparable items and LLM-only findings, then judges comparable items against an acceptability threshold.LLM-only items are grouped by evidential support and structural characteristics.Source: §4.3 · p. 8
• No comparable LLM entries fell below the Sufficiently Equivalent threshold, and Exact and Equivalent matches showed strong semantic alignment with expert annotations.The evaluation classified comparable outputs by equivalence to the manual reference and treated Exact and Equivalent matches as good; sufficiently or partially equivalent matches were acceptable.Source: §4.3 · p. 8
• LLM-only entries included 24 over-fragmentations, 9 attacks used for testing, 6 unvalidated security recommendations, and 3 deployment or optimization choices.These categories describe supported entries that differ from novel standalone attack or defense contributions, including configuration and deployment decisions.Source: §4.3 · p. 9
• The authors characterize LLM extraction as a high-recall assistant that expands the graph’s representation, while retaining expert review before integration.Users can inspect, validate, merge, or discard extracted entries.Source: §4.3 · p. 9

5.1. Insights for Academia

• Excluding xApps and Near-RT RIC yields 7 attacks, 5 defenses, and 3 preventive measures; 3 attacks and 2 defenses focus on the Fronthaul Interface [32],,,.Across the full corpus, 32 attacks, 32 defenses, and 12 preventive measures deduplicate to 18, 21, and 9 distinct works, respectively; E1 and F1 have no documented potential threats in the O-RAN threat model.Source: §5.1 · pp. 9–10
• The analysis finds uneven empirical coverage: Near-RT RIC and xApps are well-covered, while critical infrastructure components are neglected.For attacks, O-Cloud (55), Non-RT RIC (47), SMO (39), External Components (39), and O-CU (27) are prioritized for more empirical work; O-RU (25) and UE (24) also need defense work.Source: §5.1 · pp. 9–10

5.2. Insights for Operators

• Two fuzzing papers account for 18 of the 20 paper-associated CVEs, while four works disclosed 23 of 27 total CVEs.Three security researchers are responsible for 24 CVEs; several listed O-RAN and related software projects have no disclosed CVEs.Source: §5.2 · p. 10

5.3. Insights for Governments and Regulators

• Availability-threat degrees are 4 each for O-DU and O-RU, and 2 each for Non-RT RIC and Near-RT RIC.O-DU/O-RU threats include unauthorized access to layer 1 OFH interfaces and PTP spoofing or interception; the section recommends physical security and tamper-proofing.Source: §5.3 · p. 10

5.4. Insights for O-RAN Software Developers

• Memory-safety issues dominate the observed CWE anti-patterns, including improper array-index validation (3), out-of-bounds writes (3), and buffer overflows (2).The section also identifies resource-exhaustion issues and reachable assertions, recommending memory-safe languages, mitigations, continuous testing, access control, and semantic validation.Source: §5.4 · pp. 10–11

6. Future Research Directions

• The database is designed to extend beyond O-RAN, with spreadsheet-backed ground truth and a GUI-supported workflow for incorporating attacks, defenses, and components.The authors advocate a public repository for community-driven updates as new findings emerge.Source: §6 · p. 11
• Future work should address uneven research coverage, including understudied O-Cloud, Non-RT RIC, and SMO components and E1 and F1 interfaces without documented threats.The paper also notes that defensive mechanisms significantly outnumber demonstrated attacks.Source: §6 · p. 11

7. Conclusion

• The tool distills information from industry, academia, and government into a common analytical representation for O-RAN security.The authors describe it as enabling an ontological perspective and a guided approach to identifying important risks and future work.Source: §7 · p. 11
• A schema-constrained LLM module generates machine-checkable, ontology-aligned records, while a GUI supports reproducible, human-supervised updates as specifications and literature evolve.Source: §7 · p. 11

7.1. Access to Graph Database

• The artifact repository contains deployment instructions and supported-browser information; Figure 10 guides navigation of the database browser.Double-clicking a returned component retrieves connecting nodes.Source: §7.1 · p. 15, Figure 10 · p. 17

7.2. Discovered Typographical Errors

• Table 5 lists typographical errors identified in O-RAN specifications after database ingestion.Source: §7.2 · p. 15, Table 5 · p. 15

7.3. Example Queries

• Listings 2–11 provide example queries; Listing 7 returns software with no discovered CVEs, while Listing 8 returns targets of components or interfaces whose threats are high severity but low likelihood.Source: §7.3 · pp. 15–16