The increasing complexity of cyber threats, combined with the dispersion of information across multiple independent data sources, underscores the need for a structured, formal, and interoperable representation of vulnerability-related knowledge. Existing datasets, although comprehensive within their scopes, often lack semantic alignment and explicit connections between key entities such as vulnerabilities, weaknesses, and attack patterns. In this work, we present an enhanced ontology-based framework for vulnerability knowledge representation that systematically improves upon existing theoretical models through data-driven design principles. Our ontology model address critical inconsistencies between theoretical frameworks and real-world vulnerability databases by conducting a comprehensive analysis of actual data structures from CVE, CWE, CAPEC, and CPE repositories. We demonstrate the practical applicability of our framework through the implementation of a multi-model NoSQL database populated with real vulnerability data and validate its efectiveness using SWRLbased inference rules that derive new knowledge from existing relationships. The resulting knowledge base enables automated reasoning about attack chains, vulnerability exploitation patterns, and security relationships, providing a foundation for advanced cybersecurity analysis.
The continuous evolution of cyber threats has underscored the need for structured, interoperable vulnerability datasets [1]. Key security repositories include CVE [2], CWE [3], CPE [4], and CAPEC [5]. Our work uses data from the National Vulnerability Database (NVD) [6], which enriches the foundational CVE list maintained by MITRE [7] with additional metadata and CVSS [8] severity scores.
Despite their richness, these repositories exhibit significant heterogeneity in data formats and classification schemas, preventing comprehensive integrated analysis [ 9, 10]. CVE and CWE use JSON APIs or XML [11] with varying structures, CAPEC employs XML with a distinct taxonomy, and CVSS follows a unique scoring syntax. This fragmentation limits security analysts’ ability to understand complete attack landscapes and assess cascading risks [12, 13].
To address this gap, we present a practical ontology model that bridges heterogeneous vulnerability sources through systematic adaptation of existing ontological frameworks [14] to real-world database constraints. Our contribution transforms established cybersecurity ontologies [15, 16] into databasecompliant schemas that preserve semantic relationships while accommodating actual field structures and referential constraints in CVE, CWE, CPE, and CAPEC repositories.
The use of ontologies in vulnerability management and security risk assessment has matured from early eforts focused on general-purpose security models [ 17] to more refined approaches tailored to the representation and reasoning of vulnerability-specific data [ 15, 14]. A central goal in this domain has been the establishment of standardized, interoperable schemas that consolidate information from structured vulnerability repositories such as CVE, CWE, and CAPEC [14]. The ontologies in this field often aim to formalize relationships among vulnerabilities, weaknesses, and attack patterns, allowing automated reasoning over causal chains and shared characteristics. In particular, inference rules have been introduced to support the identification of consequences, causal dependencies, and congeneric relationships between vulnerabilities [14], facilitating a deeper understanding of their systemic impact. Alongside this structural modeling, some approaches have extended the scope of ontology to include contextual entities such as IT products, threats, countermeasures, and even external intelligence sources like social media [16, 18], and also for obfuscation in the crawling phase [19]. This broader perspective improves the ontology’s ability to represent real-world attack surfaces and supports more comprehensive risk assessments. Standards from organizations such as NIST and CVSS are frequently adopted to ensure alignment with established security frameworks [16, 17], promoting compatibility with existing tools and methodologies.
Despite these advancements, a number of limitations remain. In many cases, product-specific semantics and real-time threat context are not suficiently modeled [ 15], limiting the applicability of these ontologies in dynamic environments. Furthermore, while inference mechanisms are increasingly integrated, their expressiveness and scalability in large, heterogeneous systems are still underexplored. Overall, the body of work reflects a steady progression toward more expressive and interoperable knowledge models, but there remains a need for deeper integration of dynamic, product-level, and cross-domain information to fully support operational cybersecurity decision making.
In this work we improve the general top ontology model proposed by [14] to better represent and integrate real repositories related to software vulnerability. In particular, our ontological model enhances the framework through systematic evaluation of its coherence with real-world vulnerability databases. We identified critical inconsistencies between the theoretical model and actual data structures: certain ontological properties were absent from real data sources, while important database attributes lacked theoretical representation. Our enhanced model addresses these limitations, ensuring full coherence with actual database schemas.
We defined four core entity types— Vulnerability, Weakness, Attack Pattern, and Product—corresponding to CVE, CWE, CAPEC, and CPE standards. Properties were systematically selected based on conceptual importance and actual database presence. Relationships are defined through object properties that capture semantic connections in real datasets, such as hasWeakness linking vulnerabilities to associated weaknesses with exact relationship metadata found in CVE-CWE mappings. Our complete model structure is shown in Figure 1, and accessible in this Zenodo repository1.
We included a separate CWE Category class for category-level weaknesses, which represent broader groupings distinct from individual CWE entries. While NIST discouraged CVE-to-category mappings since 2019 and these account for < 0.1% of records, we retain them to distinguish entries with less granular information from fully described weaknesses with complete technical attributes.
Our enhanced Vulnerability class improves upon the ontological model of [14] through systematic analysis of real data. Key enhancements address critical limitations in the original framework:
CVSS Metrics Integration: While [14] fragmented CVSS data into separate attributes, we consolidated all CVSS parameters into a single, cohesive property maintaining semantic integrity and better alignment with NIST data schemas [8, 6].
Enhanced References Structure: Our model extends the original URL-only references by adding a "tags" sub-property that classifies reference types, improving semantic reasoning capabilities for vulnerability analysis [2].
Product Relationship Refinement: Unlike the original model, we integrate direct relationships with CPE through a separate product class, enabling comprehensive tracking of afected products [ 4]. Our CVE-CPE relationship includes metadata about specific version ranges, constituting a semantically rich association rather than simple linking.
Figure 2 shown the class diagram of the Vulnerability class. In grey we indicate the multiple subattributes of the class, and in white the simple attributes.
Vulnerability (CVE) cveId cveUrl published lastModified
status description
CVSSMetric exploitabilityScore impactScore referenceUrl referenceTags
CVSSData cvssVersion vectorString baseScore baseSeverity attackVector attackComplexity privilegesRequired userInteraction
scope confidentialityImpact integrityImpact availabilityImpact
The CWE class represents software and system weaknesses at varying levels of abstraction, capturing both their nature and the contexts in which they can be encountered or exploited. We enhance and refine the vulnerability ontology model through data-driven design principles, focusing exclusively on fields that are present in the oficial MITRE CWE data sources. This enhancement ensures that our improved ontology accurately reflects the available information while maintaining practical applicability for real-world vulnerability analysis.
We refine the framework in [ 14] and deliberately exclude CWSS (Common Weakness Scoring System) components from the CWE class definition. This design decision stems from the fact that MITRE does not provide CWSS scores in their oficial data feeds, and while these scores can be calculated post-hoc, they are not inherently present in the source data. The list of attributes present in the CWE data is shown in Figure 3. We decided to maintain the likelihoodOfExploit property as it appears directly in the source data as an attribute of the CWE class. However, since the oficial data contains no information linking to CWSS calculations or scoring mechanisms, we exclude any CWSS-related properties from our CWE class definition. This approach ensures that our ontology remains faithful to the actual data structure while avoiding assumptions about unavailable information.
Among the comprehensive set of available CWE properties, we focus here on the most critical attributes for vulnerability analysis and ontology-driven inference: • description: A concise textual summary of the weakness, describing its fundamental characteristics and the types of software flaws or design omissions it encompasses. This description provides essential context for understanding how the weakness arises and what classes of vulnerabilities it may enable. • commonConsequences: A structured list of potential negative outcomes that may follow exploitation of the weakness. Each entry comprises: – Scope: the specific security property (e.g. Confidentiality, Integrity, Availability) that the exploitation violates; – Impact (optional): a technical description of the efect should an adversary successfully leverage the weakness; – Likelihood (optional): an ordinal indication of how probable each consequence is relative to others, facilitating risk-based prioritization when multiple impact scenarios exist. • potentialMitigations: A set of recommended countermeasures or design strategies designed to prevent or reduce the severity of the weakness. Each mitigation entry includes: – Phase: the software development lifecycle stage (e.g. design, implementation, testing) at which the mitigation is most efectively applied; – Strategy: a high-level approach or best practice that guides the realization of the mitigation (e.g. input validation, coding standards, runtime checks); – Efectiveness: a brief assessment of how well the mitigation addresses the weakness, including any known limitations; – Description: detailed commentary on the mitigation’s application, benefits, and potential trade-ofs. • observedExamples: References to concrete instances of weakness as observed in real-world software or hardware products, typically denoted by CVE identifiers. These examples ground the abstract weakness in actual exploitation scenarios, aiding both validation and educational analysis. • relatedWeaknesses: Links to other CWE instances that have hierarchical or peer-level relationships. Relations such as ChildOf, ParentOf, and MemberOf capture difering levels of abstraction, while PeerOf and CanAlsoBe denote lateral associations between weaknesses that share similar characteristics. This network of relations supports navigation across the weakness taxonomy and the discovery of alternate or sibling flaw patterns. • relatedAttackPatterns: Connections to AttackPattern instances in the ontology, indicating adversarial techniques that are known to exploit the given weakness. By linking weaknesses to attack patterns, the model enables automated reasoning about likely exploitation vectors and the potential chaining of attack steps.
Weakness (CWE) cweId cweUrl name abstraction cweDescription extendedDescription likelihoodOfExploit backgroundDetails
AlternateTerm termName termDescription PotentialMitigation mitigationId mitigationPhase mitigationStrategy mitigationDescription
ApplicablePlatform platformType platformClass platformPrevalence
DetectionMethod detectionMethod detectionDescription detectionEffectiveness detectionEffectivenessNotes
CommonConsequence consequenceScope consequenceImpact consequenceNote
ObservedExample observedReference observedDescription observedLink
ModeOfIntroduction introductionPhase introductionNote Note noteType noteContent
The CAPEC class represents attack patterns that describe common techniques used by adversaries to exploit weaknesses in software and systems. As in [14], our ontological model extends the framework by formally modeling CAPEC attack patterns as a distinct class within the vulnerability ontology. This extension provides a comprehensive data schema for CAPEC instances, incorporating all information ifelds that can be systematically extracted from the oficial MITRE CAPEC data sources. While the original framework in [14] established the hierarchical structure of CAPEC data (categories containing meta-patterns, with each meta-pattern having multiple detail and standard patterns), our ontological modeling reveals additional complexity beyond the five core properties initially identified by the authors. Our analysis of actual MITRE data demonstrates that standard CAPEC entries contain not only the properties defined at the meta-level but also additional attributes specific to the standard abstraction level. Furthermore, some standard CAPEC patterns can contain detail-level CAPEC patterns within their structure, creating a more complex relational hierarchy than previously captured in the literature.
To address this complexity, we have incorporated the CAPEC relatedTo property into our ontological model, enabling the representation of hierarchical relationships between CAPEC instances across diferent abstraction levels (standard, detail, category). This property captures the parent-child relationships explicitly defined in MITRE’s oficial data sources, where each CAPEC entry can be verified as either a ChildOf or ParentOf relationship with other CAPEC patterns. To distinguish between diferent types of CAPEC entries within our ontological framework, we utilize the abstraction field present in the source data, which explicitly defines whether a given CAPEC instance represents a category, meta-pattern, standard attack pattern, or detailed attack pattern. A figure of all the attribute we have considered for the Attack Pattern class is shown in Figure 4. We highlight five principal properties: • description: A concise statement that characterizes the attack pattern, specifying the context in which the attack occurs, the actor’s objectives, and the anticipated impact on the targeted systems. This field situates each CAPEC entry within real-world threat scenarios and clarifies its purpose and scope. • consequences: Analogous to the commonConsequences in the CWE class, this structured list enumerates the negative outcomes that may result from the execution of the attack pattern. Each consequence entry identifies the violated security scope (e.g. confidentiality, integrity, availability), optionally describes the technical impact, and may include an ordinal probability of prioritize the most critical outcomes. • executionFlow: A detailed, step-by-step account of the adversary’s typical sequence of actions Attack Pattern (CAPEC) capecId capecUrl capecName capecAbstraction capecDescription capecExtendedDescription capecLikelihood capecSeverity capecPrerequisites capecResourcesRequired capecIndicators capecMitigations capecExampleInstances
ExecutionFlow flowStep flowPhase flowDescription flowTechniques SkillsRequired
skillLevel skillDescription
Consequence consequenceScopes consequenceImpacts consequenceNote TaxonomyMapping taxonomyName entryId entryName
when performing the attack. Organized into phases, such as Explore, Experiment, and Exploit, the execution flow delineates the preparatory reconnaissance, trial-and-error probing, and the final exploitation steps, thereby ofering an operational view of the threat. • relatedWeaknesses: References to one or more CWE instances whose presence is a precondition for the attack pattern’s success. The association implies that any one of the listed weaknesses (though not necessarily all) must exist in the target environment to facilitate the adversary’s technique. This property enables automated linkage from attack patterns back to the underlying technical flaws. • relatedAttackPatterns: A network of lateral and hierarchical relationships to other CAPEC entries. Each Related Attack Pattern element includes an identifier and a Nature attribute that specifies the type of relation: – ChildOf and ParentOf denote abstraction levels, indicating broader or more specialized techniques; – CanPrecede and CanFollow capture sequential chaining in multi-stage attacks; – CanAlsoBe identifies patterns that, in certain contexts, may be interpreted as the target technique (note that this relation is not necessarily reciprocal); – PeerOf highlights analogous techniques that share similar objectives but do not fit other relational categories.
A fundamental distinction between our enhanced ontological model and the framework presented in [14] lies in the explicit modeling of two critical classes that were absent from the original work: the CPE (Common Platform Enumeration) class and the CWECategory class. These additions represent a significant advancement in achieving better coherence with the actual data structures present in authoritative vulnerability databases, moving beyond the simplified representations proposed in prior research.
The CPE class represents software and hardware platforms that may be afected by vulnerabilities. Unlike [14], where platform information was treated as simple textual attribute, our ontological model elevates
Part
Vendor ProductName
Version categoryId categoryURL categoryName categorySummary mappingNotes
Usage Ratonale Comments Reasons
CPE to a first-class entity with dedicated properties and relationships. Our data-driven analysis of oficial CVE databases reveals that CPE entries follow a structured format encompassing multiple semantic components (part, vendor, product, version, update, edition, language, software edition, target software, target hardware). To maintain ontological clarity while preserving essential semantic information, we have selected four core attributes that provide maximum value for vulnerability analysis: • part: Distinguishes between applications, operating systems, and hardware devices • vendor: Identifies the responsible organization or manufacturer • product: Specifies the exact software application or hardware product • version: Indicates the particular release or version number
The CWECategory class represents an entirely novel contribution absent from [14], addressing the hierarchical organization of weaknesses within the CWE taxonomy. Our enhanced model recognizes that MITRE organizes weaknesses into conceptual categories that group related security concerns. Our CWECategory class captures three fundamental properties derived directly from MITRE’s oficial data structure: • categoryId: The unique identifier assigned by MITRE to distinguish diferent weakness categories • categoryName: The human-readable title that describes the category’s focus area • categorySummary: A comprehensive description of the types of weaknesses contained within the category
This categorical modeling enables the representation of MemberOf relationships between individual CWE instances and their parent categories, facilitating automated reasoning about weakness taxonomies and supporting more sophisticated vulnerability analysis workflows. The absence of such categorical representation in [14] limited the framework’s ability to capture the full semantic richness of the CWE knowledge base, a gap that our enhanced ontological model explicitly addresses.
To populate our ontology with real-world data, we developed a comprehensive pipeline using the Scrapy [20] framework for scalable, asynchronous web crawling and parsing. The process is shown in Figure 6.
The pipeline comprises three main stages:
First, in the CVE Harvesting stage, our custom Scrapy spider targets the NIST CVE API endpoint. Using Scrapy’s built-in concurrency, the spider issues multiple parallel GET requests to retrieve the full set of CVE entries of interest. Upon receiving each JSON response, we extract core fields such as the CVE
CWE
CAPEC CVE identifi er Textual Description CVSS vector severity Timestamp List of CWE identifi er
CWE Name Descriptive Summary Integration information List of CAPEC
Filtering CAPEC
CAPEC ID Properties
Full CAPEC catalog CVE identifier, textual description, CVSS severity vector, and publication timestamp, as well as the list of associated CWE identifiers embedded within the CVE metadata.
Second, stage CWE Enrichment enriches each harvested CVE record with detailed weakness information. For every CWE ID collected in the previous step, the spider issues an on-the-fly GET request to the MITRE CWE API. This request returns structured details for the weakness, including its oficial name, descriptive summary, how such a weakness can be introduced and mitigated, and to what CAPEC it’s exploited by. By performing this enrichment inline, rather than maintaining a separate crawl or static dump of CWE data, we ensure tight coupling between CVE and CWE records and reduce potential synchronization issues.
Finally, the CAPEC Integration stage handles the incorporation of the attack pattern data. Because MITRE does not provide a dedicated API for CAPEC, we downloaded the complete CAPEC catalog in XML format from the oficial repository. Given the modest size of the catalog relative to the CVE and CWE datasets, we opted for a single-pass batch parsing approach: the XML file is parsed in one go to extract each CAPEC ID and other properties, which then overwrite the placeholder ID from the CWE Enrichment stage.
Throughout the crawling and parsing process, we restricted all relationships to first-level links: CVE to CWE, CWE to CWE, etc., since our primary focus is on capturing the direct associations that underlie vulnerability exploitation. This streamlined pipeline produces a consistently structured high quality dataset ready for ingestion into the ontological model.
To validate the efectiveness and practical applicability of our enhanced ontological model, we designed and implemented a comprehensive empirical evaluation framework. This validation approach involves constructing a real-world vulnerability database populated according to our ontological schema, followed by systematic testing of the model’s inference capabilities using actual vulnerability data.
For this purpose, we selected ArangoDB [21], a multi-model database that natively supports both graph and document data structures. This choice was specifically motivated by the hybrid nature of our ontological model, which requires eficient storage and querying of both rich entity attributes (documentoriented) and complex inter-entity relationships (graph-oriented). The multi-model approach enables us to preserve the complete semantic richness of vulnerability data while supporting sophisticated ontological reasoning operations. Following the data integration pipeline described above, the structured vulnerability dataset was systematically ingested into ArangoDB. The five core entity types—CVE, CWE, CWE Category, CAPEC, and CPE—were implemented as vertex collections, preserving their rich JSON document structure while enabling graph-based operations. The ontological relationships were materialized as edge collections, including causedBy, exploitedBy, afects, hasCategory and relatedTo connections. A subsection view of the graph database is shown in Figure 7.
In order to demonstrate the efectiveness and flexibility of our model and its suitability for the data structure, we have developed an inference rule in SWRL (Semantic Web Rule Language) [22] that are specifically adapted to the structure of our dataset. This rule leverages the existing relationships between CVE, CWE, and CAPEC to infer new knowledge about the security landscape, enhancing the analytical capabilities of our vulnerability ontology framework [23]. Table 1 presents the pattern terms used in our inference rule, along with their definitions.
We decided to implement an inference rule that identifies potential attack chains by connecting vulnerabilities that share related weaknesses and afect the same platform or product, helping to uncover multi-stage attack scenarios.
CVE(?1) ∧ CVE(?2) ∧ CWE(?1) ∧ CWE(?2)∧ CAUSED_BY(?1, ?1) ∧ CAUSED_BY(?2, ?2)∧ RELATED_TO(?1, ?2) ∧ nature(?, "ChildOf")∧
CPE(?) ∧ AFFECTS(?1, ?) ∧ AFFECTS(?2, ?)
→ potentialAttackChain(?1, ?2)
(
To assess the efectiveness of the proposed inference rule, we implemented a database query using AQL (Arango Query Language) [21], translated from the inference rule we have defined. The following code shows the query used, and a sample of the results obtained is shown in Table 2. FOR v1 IN CVE
FILTER v1._key == "2022-40521" FOR v2 IN CVE
FILTER v2._key == "2016-10408" FOR w1 IN CWE
FOR cb1 IN CAUSED_BY
FILTER cb1._from == v1._id AND cb1._to == w1._id FOR w2 IN CWE
FOR cb2 IN CAUSED_BY
FILTER cb2._from == v2._id AND cb2._to == w2._id FOR rt IN RELATED_TO
FILTER rt._from == w1._id AND rt._to == w2._id AND rt.nature == "ChildOf" FOR c IN CPE
FOR a1 IN AFFECTS
FILTER a1._from == v1._id AND a1._to == c._id FOR a2 IN AFFECTS
FILTER a2._from == v2._id AND a2._to == c._id RETURN { "cve1": v1._key, "cve2": v2._key, "parent_cwe": w1._key, "child_cwe": w2._key, "affected_cpe": c._key, "potentialAttackChain": CONCAT(v1._key, " -> ", v2._key)
The results in Table 2 demonstrate a concrete attack chain identified by our inference rule involving CVE-2022-40521 and CVE-2016-10408, both afecting multiple Qualcomm firmware platforms. CVE2022-40521 is caused by CWE-287 (Improper Authentication), while CVE-2016-10408 is caused by CWE-284 (Improper Access Control). The inference rule successfully identified this as a potential attack chain because CWE-284 is a child weakness of CWE-287 in the MITRE taxonomy, representing a natural escalation path where an attacker could exploit authentication bypass vulnerabilities to gain unauthorized access control.
This specific example illustrates a temporal attack chain spanning six years (2016-2022) across multiple Qualcomm firmware variants, including APQ8037, 9206 LTE modem, SD820, and SD626 platforms. The persistence of related weaknesses across diferent firmware generations creates a compound security risk where an attacker familiar with the older access control vulnerability (CVE-2016-10408) could leverage similar authentication bypass techniques against newer firmware (CVE-2022-40521). This finding highlights how firmware security debt accumulates over time, as legacy vulnerability patterns can inform exploitation strategies against newer systems that inherit similar architectural weaknesses. The practical significance of this discovered chain lies in its cross-platform nature across Qualcomm’s product ecosystem. Security analysts managing Qualcomm-based systems should consider these vulnerabilities as interconnected threats rather than isolated incidents, particularly when multiple firmware versions coexist in the same organizational environment. The ability to automatically identify such temporal and cross-platform attack chains enables more comprehensive vulnerability assessment and prioritized remediation strategies that account for the compound risk of related weaknesses persisting across product generations.
In this paper we presented an enhanced data-driven ontology framework that systematically improves
upon existing theoretical models for vulnerability knowledge representation. Our key contribution lies
in addressing the critical gap between theoretical ontological frameworks and real-world vulnerability
database structures through a comprehensive analysis of actual CVE, CWE, CAPEC, and CPE data
sources. The enhanced ontological model introduces several important improvements over prior
work: (
The resulting knowledge base provides a foundation for advanced cybersecurity analysis, supporting both graph-based querying and automated reasoning about attack escalation paths. Future work will leverage this structured knowledge base to support natural language interfaces powered by Large Language Models [24, 25], enabling intuitive query capabilities and dynamic knowledge extraction across vulnerability relationships.
We acknowledge financial support from the PNRR MUR project PE0000013-FAIR.
The author(s) have not employed any Generative AI tools