diniscruz.ai / writing / Knowledge Graphs

Semantic OWASP: Leveraging GenAI and Graphs to Customise and Scale Security Knowledge

By Dinis Cruz and ChatGPT Deep Research · · 38 min read

PDF Audio

Contents · 11 sections
  1. Podcast
  2. Infographic
  3. Introduction
  4. Limitations of Current OWASP Documentation Projects
  5. Towards a Semantic Knowledge Graph Ecosystem
  6. Leveraging Semantic Web Technologies and LLMs
  7. Inspiration from MyFeeds.ai and The Cyber Boardroom
  8. A Semantic Approach for OWASP: From Vision to Reality
  9. Open Source Tools and Workflow Alignment
  10. Recommendations for Adopting the Semantic Model
  11. Conclusion

See also this slides and video presented at OWASP's London Chapter Meeting

Podcast

Infographic

Open the infographic in a new tab →

Introduction

Open Web Application Security Project (OWASP) documentation projects – such as the OWASP Top 10, Application Security Verification Standard (ASVS), the Web Security Testing Guide and many others – are widely used to educate and guide the security community. These resources have become de-facto standards for identifying risks, defining security requirements, and outlining testing practices.

However, as the volume and diversity of software grows—and new technologies like AI change how information is consumed—the current format of OWASP knowledge bases is starting to show limitations.

Most OWASP documentation exists as static text (PDFs or web pages), which is great for human reading but makes it difficult to extract specific information, automate usage, or tailor content to different needs.

This paper advocates for a shift to a semantic knowledge graph ecosystem for OWASP content – an approach that would make OWASP knowledge more accessible, customizable, and interconnected.

By leveraging semantic web technologies and large language models (LLMs), OWASP can transform its guides and standards into a machine-readable, linked knowledge base that community members and tools can query, adapt, and build upon in a context-aware manner.

To remain impactful, OWASP must evolve its content delivery to support greater accessibility, customization, and interoperability across tools, industries, and languages.

Limitations of Current OWASP Documentation Projects

Despite their value, OWASP’s flagship documentation projects have inherent limitations in accessibility, customization, and interconnectivity:

These limitations stem from an older paradigm of publishing knowledge in fixed documents. As the security field demands more agility and as developers increasingly seek quick, tailored answers (often via AI assistants or search), it’s clear that OWASP needs to modernize the format of its knowledge base. The goal is not to replace the familiar human-readable guides, but to augment them with a richer, machine-readable and linkable layer.

This is where a semantic knowledge graph approach comes in.

Table 1 below summarizes some of these challenges and how a new approach could address them:

Current Challenge Traditional OWASP Docs (Today) Semantic Graph Approach (Proposed)
Formats & Accessibility Static HTML/PDF pages. Hard for tools to parse; translations are separate PDFs. Structured data (e.g. JSON-LD/RDF). Queryable by tools; content can be delivered in multiple languages on demand.
Customization of Content One-size-fits-all content. Users manually filter or copy what they need. Filterable graph queries (by topic, industry, risk). Automated generation of custom lists or checklists per context.
Interconnectivity of Knowledge Minimal explicit links (manual references). Siloed projects with overlapping info. Rich links between nodes (vulns, controls, tests). Unified view of OWASP knowledge; easy traversal across projects.
Update & Maintenance Periodic large releases (e.g. Top 10 every few years), requiring manual cross-update between projects. Continuous integration of new data. Graph can be incrementally updated; links help propagate changes (e.g. new vuln auto-linked to relevant controls).
Consumption by AI/Tools AI assistants must parse lengthy text (risk of missing context or errors). Tools lack official data feeds. Graph is machine-readable, enabling AI to retrieve precise facts or relationships. Official data feeds/APIs can be provided to tools.

Towards a Semantic Knowledge Graph Ecosystem

Imagine all OWASP content – the Top 10, ASVS, Testing Guide, Cheat Sheets, etc. – not as separate books, but as a single interconnected knowledge graph. In this graph, the fundamental concepts of application security (e.g. vulnerabilities, weaknesses, controls, requirements, test procedures) are the nodes, and the relationships between them (e.g. “mitigates”, “is example of”, “belongs to category”, “requires testing of”) are the edges. In essence, OWASP’s written knowledge would be modeled in a way that is semantic (meaningful to computers) and machine-readable, while still remaining human-comprehensible through various front-ends.

In a semantic knowledge graph ecosystem:

Achieving this vision relies on two key technology sets: semantic web standards and LLMs (AI) for content processing. Semantic web standards (like RDF, OWL, JSON-LD) provide the framework to represent and store the knowledge graph in a structured way that others can use. But manually converting OWASP’s extensive text into a semantic format would be a monumental task – this is where large language models come in, automating the extraction of structured knowledge. In the next section, we’ll explore how LLMs and semantic technology together can turn the current OWASP documentation into a rich knowledge graph with far less effort than one might imagine.

Leveraging Semantic Web Technologies and LLMs

The concept of a knowledge graph for OWASP isn’t entirely new – it aligns with Tim Berners-Lee’s vision of a Semantic Web where data is structured for machines – but what’s new is the feasibility. Traditionally, creating semantic data from free text required extensive manual curation or brittle natural language processing scripts. Today, large language models can do much of the heavy lifting in extracting, normalizing, and linking information from text into a structured form.

Semantic Web Building Blocks: The foundation of a knowledge graph is an ontology or schema – a formal way to describe types of entities and relationships. For OWASP content, we would define, for example, that there are entities like Vulnerability, Requirement, Control, BestPractice, Threat, etc., and relationships like mitigates, is example of, related to, has severity, maps to CWE, and so on. We might say an OWASP Top 10 risk is a type of Vulnerability (category) that has a description, has example CWEs, and is mitigated by certain ASVS Requirements. An ASVS Requirement could be defined to verify certain Controls or techniques, and address certain Vulnerabilities. By defining these relationships, we essentially create a web that a machine can navigate just as naturally as a person follows links in a document.

LLM-Assisted Extraction: Large language models can be prompted to read OWASP text and output data according to the defined schema. For example, we could feed the text of the OWASP Top 10 page for “Broken Access Control” into an LLM with instructions to produce a JSON object containing fields like “Risk Name”, “Description”, “CWE Mapping”, “Related ASVS Requirements”, “Related Testing Guide Sections”, etc. Modern LLMs are capable of producing this kind of structured output when guided properly. In fact, an approach used by Dinis Cruz and team (which we’ll detail soon) employs OpenAI’s ability to generate structured JSON outputs by providing a schema – meaning the LLM is constrained to fill in specific slots with the relevant info (Building Semantic Knowledge Graphs with LLMs: Inside MyFeeds.ai's Multi-Phase Architecture). This reduces hallucination and yields a deterministic result. We might get a JSON like:

{
  "name": "Broken Access Control",
  "owasp_top10_year": 2021,
  "description": "...",
  "cwe_refs": ["CWE-284", "CWE-285"],
  "asvs_controls": ["V4.1.2", "V4.2.1"], 
  "testing_guide_sections": ["4.6.1", "4.6.2"],
  "related_topics": ["Access Control", "Authorization", "Privilege Escalation"]
}

This is just an illustrative snippet, but it shows how the rich text of OWASP documents can be transformed into data. The same can be done for each ASVS requirement (e.g., parse it into a structured record including its verification level, category, etc., plus linking it to any risks like Top 10 categories or CWE it addresses). Testing Guide chapters can be processed to link each test scenario to the relevant vulnerability or OWASP category. Crucially, the LLM doesn’t have to invent these links out of thin air – many are implicitly or explicitly mentioned in the texts (for instance, Top 10 entries list example CWEs, ASVS often cites if a requirement maps to a particular issue). The LLM can surface these and put them into the JSON under the right fields.

Once the LLM extracts data for all documents, we feed those JSON objects into a graph database that supports semantic queries. An open source tool particularly suited for this is MGraph-DB, a serverless graph database recently published by the OWASP community. MGraph-DB was designed to easily convert JSON outputs from LLMs into graph nodes and edges. In other words, it takes those structured pieces and merges them into the growing knowledge graph. Each JSON object becomes part of the graph, and where identifiers match (say two JSON entries both refer to "CWE-284"), they can be merged or linked as the same node. MGraph-DB’s memory-first and serverless design means it can scale the integration of lots of pieces quickly, which is ideal for building a large graph from many text sources.

Ensuring Quality and Consistency: One might worry about errors – can we trust the LLM to get all this right? The key is an iterative, human-in-the-loop process. The LLM provides a first draft of the graph, which can then be reviewed and refined by OWASP project experts. Importantly, because the LLM output is structured and not just prose, reviewing it is easier: you can spot if a link is missing or incorrect (e.g., an ASVS requirement was not linked to a Top 10 category it obviously relates to) and add it. Over time, the community can build a refined ontology and feed that back into the LLM prompt to guide extractions more strictly. In fact, Dinis Cruz notes that initially they let the LLM pick relationships freely, but the goal is to progressively enforce a stronger predefined taxonomy as human feedback is incorporated. In OWASP’s case, this means we might start with simple relationships that the LLM can infer, and later formalize an OWASP ontology so the LLM knows exactly which relations to use.

Semantic Enrichment: The knowledge graph can be enriched with external data as well. OWASP content often references external standards like CWE, CAPEC, CVE, PCI DSS, etc. These can be nodes in the graph too, effectively connecting OWASP to the larger security knowledge ecosystem. This opens possibilities like: given a CVE (vulnerability in the wild), one could trace which CWE it’s classified under and thus which OWASP Top 10 category and ASVS controls are relevant – a powerful cross-reference for defenders. All of this is facilitated by adopting semantic web-friendly identifiers and formats (for instance, using CWE IDs as unique keys in the graph that align with MITRE’s data). The end result is that OWASP’s advice doesn’t live in a vacuum but is part of a linked network of security knowledge.

In summary, by combining semantic web technologies (to model and store knowledge) with LLMs (to extract and populate that knowledge at scale), OWASP can transform its corpus into a living, queryable knowledge graph. This graph would dramatically improve accessibility (both for humans and machines), enable customization for various needs, and tightly interlink all pieces of guidance for a more holistic understanding.

We have a compelling proof-of-concept of this approach in action, which we’ll look at next: the work done by Dinis Cruz in projects like MyFeeds.ai and The Cyber Boardroom.

Inspiration from MyFeeds.ai and The Cyber Boardroom

To ground this in reality, consider the approach pioneered by OWASP veteran Dinis Cruz with two recent projects: MyFeeds.ai and The Cyber Boardroom. These projects deal with a different domain of content (news articles and executive reports), but they showcase the power of using LLMs to build semantic knowledge graphs and generate personalized outputs – exactly the kind of workflow we envision for OWASP.

MyFeeds.ai is a system that creates personalized cybersecurity news feeds. Under the hood, it uses a multi-phase LLM pipeline to turn unstructured news articles into a structured knowledge graph and then produce a tailored summary for a specific persona (like a CEO, CISO, developer, etc.). The process works in four main phases:

  1. Entity and Relationship Extraction (Article Graph) – MyFeeds takes an incoming article (via RSS feed), and calls an LLM to extract key entities and facts from that article. For instance, if the article is about a new data breach, the LLM might output a structured summary: entities such as "Company X", "Ransomware", "Data Breach", and relationships like "Company X suffered Data Breach via Ransomware". This comes back not as free text but as a JSON object with defined fields (using OpenAI’s structured output mechanism). Essentially, the article is converted into a mini knowledge graph of its own content. These JSON results are then loaded into the graph database (MGraph-DB) as nodes and edges, creating what we can call an “article graph”. At this stage, each article is a separate set of nodes.

  2. Persona Graph Construction – In parallel, MyFeeds constructs a “persona” graph that represents the interests and context of the target reader. For example, if the persona is a CEO concerned with business impact, the persona graph might include nodes like "Financial Loss", "Reputation Impact", "Regulatory Compliance", etc., indicating topics the CEO cares about. This can be created by an LLM as well, given a prompt describing the persona’s concerns. In Dinis’s MVP, personas were somewhat predefined (hard-coded profiles for CEO, CISO, etc.), but they are represented as data just like the articles. Now we have two graphs: one for the content of each article, and one for the persona.

  3. Relevance Mapping – The next challenge: determine which articles are relevant to the persona. MyFeeds does this by essentially “connecting” the article graph to the persona graph via another LLM step. The LLM is given the persona’s entity list and an article’s entity list and asked to find matches or map relationships between them. The output is a set of mappings with scores – e.g., it might find that an article about "Ransomware causing data breach" is highly relevant to a persona concerned with "Operational Disruption" and "Financial Loss", yielding a relevance score. This step results in an enhanced article node that now links to persona interests and carries a relevance rating. Notably, by doing this with structured data (and not asking the LLM to just summarize text arbitrarily), the process remains pretty deterministic and avoids hallucination; the LLM is working only with the facts extracted from the article and persona definition. At the end of Phase 3, the system has identified, say, 5 articles out of 50 that are most relevant to the CEO persona, each annotated with which key points align with the CEO’s concerns. All the while, provenance is preserved – the graph nodes still link back to the original article content, which is even included in the data for transparency.

  4. Personalized Summary Generation – Finally, MyFeeds uses an LLM one more time to generate a synthesized output for the persona, using the curated relevant articles and their linked facts. Essentially, it asks the LLM to “write a blog post/newsletter for [Persona] summarizing the insights from these articles” and provides the structured data of those articles as context. Because the input includes the key facts and even the original text snippets, the LLM can produce a coherent summary with direct references. The result is a personalized report – for example, a CEO’s weekly cyber brief that highlights just the business-impacting security news. Crucially, this final LLM output is also captured as structured data (it returns JSON objects for each section of the summary) rather than just free-form text. This allows MyFeeds to easily format it for various outputs (HTML, Markdown, etc.) and even publish it automatically. In Dinis’s demo, the output was published to a Ghost blog site via API, generating a nice web page for the persona. The key takeaway: the LLM was used to transform selected articles and their connected entities into a personalized blog post, effectively writing a custom newsletter based on the underlying knowledge graph.

This multi-phase approach demonstrates a pattern that could be mirrored for OWASP content: - Instead of news articles, we have OWASP documents (Top 10 chapters, ASVS requirements, etc.) to extract entities/relationships from. - Instead of a CEO persona, we might have a “context profile” (e.g., a particular industry or technology focus) to construct. - We then map which parts of OWASP knowledge are most relevant to that context. - Finally, we could generate a tailored guidance document (or interactive FAQ, or checklist) for that context.

The Cyber Boardroom complements this by providing a platform for user-specific feeds. If MyFeeds is the engine that produces these persona-based reports from public data, the Cyber Boardroom is a private environment where an individual user can have multiple personas, subscribe to feeds, and interact with them. Dinis integrated features like user authentication and multi-persona support there, recognizing that one person (say a CISO) might want different profiles (one for technical detail, one for board presentations, etc.). The Cyber Boardroom essentially aims to commercialize or operationalize the personalized knowledge delivery – something OWASP could emulate in spirit by offering customizable “views” of its content to community members.

There are a few important lessons from MyFeeds.ai for our OWASP use case: - LLMs as Connectors, not Replacements: The system didn’t just ask the AI open-ended questions; it broke the problem into stages and used structured prompts and outputs at each stage. This aligns with a principle Dinis highlighted: use LLMs only for what they are the only option for, and use code for everything else. In building an OWASP knowledge graph, we would do similarly – use LLMs to bridge the gap where writing parsing code is too complex (like understanding natural language explanations), but use deterministic algorithms to assemble, query, and present the data whenever possible. This yields more repeatable and explainable results.

In summary, the success of MyFeeds.ai and The Cyber Boardroom in extracting and delivering tailored knowledge from unstructured content underlines the viability of a semantic, LLM-assisted approach. If we apply those principles to OWASP’s content, we can envision a system where OWASP knowledge is not just a set of static documents, but a service: an intelligent, queryable, customizable knowledge base accessible to developers, testers, managers, and automated tools alike.

A Semantic Approach for OWASP: From Vision to Reality

How specifically might this work for OWASP’s own projects? Let’s walk through a plausible implementation scenario, tying together all the concepts discussed:

  1. Define the OWASP Ontology – Start by outlining what entity types and relations we need to represent OWASP content. Likely entities: Risk Category (e.g., Top 10 entries, vulnerability categories), Requirement (ASVS items, MASVS for mobile, etc.), Test Case (from Testing Guide), Best Practice (from Cheat Sheets or Proactive Controls), Tool/Project (like references to OWASP tools or external tools), etc. Define relations like “addresses” / “mitigates” (a requirement mitigates a risk, a test addresses a requirement), “has weakness” (a risk category links to CWE weakness types), “related to” (for more general associations), “prerequisite for” or “part of” (hierarchical relations, e.g., ASVS Chapter contains Requirements). This ontology would be developed collaboratively with OWASP project leaders to ensure it makes sense for all content. The good news: much of this structure is intuitive and already informally present in the docs (e.g., ASVS has chapter-section numbers, Top 10 categories have CWE mappings).

  2. Convert Text to Structured Data with LLMs – Using the ontology as a guide, process each OWASP document:

    • OWASP Top 10: For each Top 10 item, parse out its title, description, example attack scenarios, example CWEs, and any references to other OWASP projects. The LLM might read the narrative and output something like Risk = “Injection”, Impact = “data loss, account takeover”, CWE_List = [79, 89, ...], Related_ASVS = [“V5.3.2”, “V5.3.3”] if it can identify those in text or from its knowledge. (We may need to prompt it with a hint like “map this to ASVS if possible”; alternatively, we can do a post-processing step to link by CWE overlap – multiple strategies exist.)
    • OWASP ASVS: Convert each requirement into an object with fields: e.g., ID = 4.2.3, Description = "...ensure X...", Level = 2, Category = “Authentication”, Related_Top10 = [A2-2017] if it maps (some ASVS items explicitly say “(Mapping: OWASP Top10 A2)” which the LLM can capture). ASVS also has an official JSON in its repo which we can ingest directly as a starting point, to avoid re-extracting what's already structured.
    • OWASP Testing Guide: Each section (e.g., test for SQL injection) can be summarized into fields: Test Name, Description of approach, Related Vulnerability/Risk, Tools (if mentioned), etc. The Testing Guide might be the most textual, but it usually is organized by vulnerability type, so the LLM will likely latch onto those headings.
    • Cheat Sheets and Other Guides: These can be treated similarly – identify the key recommendations and link them to the vulnerabilities or topics they address.

    At this stage we would have a large collection of JSON objects or triples that the LLM produced. We merge these into the graph database. Since multiple sources might refer to the same thing (e.g., “Injection” appears in Top10 and Testing Guide), part of the merging involves reconciling them. This could be done by common identifiers: e.g., if the Top 10 item had CWE-89 and a Testing Guide section also mentioned CWE-89, we can link them via a common CWE node. Or simply by name matching with verification by the ontology (the ontology might say that if two Risk nodes have the same name “Injection”, and maybe same CWE set, they are the same concept node). This reconciliation step might require some manual review to ensure correctness, but tools can assist (for example, we can automatically flag potential merges).

  3. Augment with Context Tags – Once the core graph is built, we can enrich nodes with metadata that will enable the personalized and context-aware features:

    • Tag certain vulnerabilities or controls with industry sectors if applicable (maybe gleaned from OWASP Vertical Knowledge Projects if any exist, or from experience – e.g., “PCI” or “Healthcare” tags).
    • Tag requirements with “High”, “Medium” if they are critical in certain threat models (ASVS has levels which serve this purpose to some degree, but we could extend).
    • Mark content with regional relevance if any (for example, if a particular guideline addresses GDPR explicitly, tag it “EU”). Few OWASP items are region-specific, but data privacy ones might map to regions.
    • Add multilingual labels: use LLMs or existing translations to add, say, a Spanish description field on each node. Because the graph is language-agnostic in structure, you can attach multiple language versions of text to the same node. This would allow dynamic switching of language in output. OWASP already has translations (like ASVS in several languages; those can be aligned to the same nodes in the graph rather than being separate documents.

  4. Enable Queries and Views – With the populated knowledge graph in place, we build interfaces to use it:

    • A simple Graph Query API (could be GraphQL or SPARQL or even REST endpoints) that developers and tools can query. For example, an API endpoint /owasp/risk/Injection could return a JSON with all linked info about Injection (related requirements, test cases, etc.). Or a query GET /owasp/asvs?vuln=Injection returns all ASVS requirements related to Injection.
    • An Interactive Explorer for humans: a web UI where you start at a node (say “Broken Access Control”) and visually or navigationally explore links (see related ASVS items, click to see their details, then to testing procedures, etc.). This could be similar to how some documentation sites have link maps, but powered by the underlying graph for completeness.
    • A Customization Wizard: a tool where a user can input their context (industry, tech, threat concerns) and it generates a tailored OWASP guide. This is where we bring in the persona concept. We could have preset personas like “Web App Developer”, “Cloud SaaS Provider”, “Mobile App Pen tester”, etc., each basically a filter or subgraph focusing on certain areas. The user picks one (or configures one by selecting interests), and the system produces a custom view – maybe a PDF or web page that collates the relevant OWASP content. LLM can be used here to stitch together narrative if needed (e.g., writing an introduction or summary for the custom guide), but all the substance comes from the graph data (ensuring accuracy).
    • Multilingual support toggles on the site: because nodes have multiple language text, the user could switch language and see the content in, say, Portuguese. If a piece isn’t translated yet, an LLM could translate it on the fly, and optionally that could be reviewed and added to the graph for next time.

  5. Integration with AI Assistants – By having OWASP’s knowledge in a structured database, even external AI systems (like GPT-based chatbots) can more reliably use it. For instance, one could build an OWASP ChatGPT plugin that queries the OWASP knowledge graph when asked security questions, rather than relying on the model’s trained memory of OWASP (which might be outdated or incomplete). The plugin could fetch precise answers and even cite OWASP content properly (thanks to the provenance in the graph). This means when a developer asks “What should I do to prevent XSS in an Angular app?”, the assistant could retrieve the exact relevant nodes (perhaps OWASP Top 10 XSS description + Angular Cheat Sheet guidance) and respond with a tailored, up-to-date answer. Essentially, the OWASP knowledge graph would make OWASP content AI-ready in a responsible way.

  6. Maintenance Workflow – As OWASP projects evolve, the knowledge graph can be updated. The ideal maintenance is to bake the structured approach into the project workflows:

    • When the next OWASP Top 10 is drafted, the project could simultaneously prepare the structured data (maybe even writing content in a way that is easily pluggable into the graph – like maintaining a YAML file for each entry alongside the narrative).
    • ASVS already has a structured source; ensuring that stays synced or directly using it means minimal extra work.
    • Encourage project leads to think in terms of data first: e.g., the next Testing Guide update could catalog each test case in a spreadsheet or YAML which then can feed the graph, instead of writing a monolithic doc.
    • The community can also help to fill gaps. Perhaps set up a small OWASP task force to continuously refine the graph – adding missing links, updating tags, incorporating new project outputs (OWASP has many projects – e.g., OWASP API Top 10, OWASP MASVS for mobile – those too can feed into this ecosystem).
    • Because the knowledge graph and underlying data formats would be open, contributors can make pull requests to them just like they do to Markdown or code today.

By implementing this, OWASP would significantly increase the utility of its content. The knowledge would no longer be locked in silos or only human-readable paragraphs; it would be an open platform that others can interact with. Consider the downstream benefits:

Open Source Tools and Workflow Alignment

One of the strengths of this proposal is that we can leverage existing open source tools and past OWASP efforts to jump-start the semantic knowledge graph ecosystem:

In essence, OWASP would be standing on the shoulders of prior work – both from within the OWASP community and the broader open source/academic community – to implement this semantic ecosystem. This lowers cost and risk. The focus shifts from “can it be built?” (because we have evidence it can) to “how do we organize and execute it within OWASP?”.

Recommendations for Adopting the Semantic Model

Adopting a semantic knowledge graph ecosystem for OWASP content is a significant transformation. It should be approached incrementally, demonstrating value at each step to gain buy-in from the community. Here are specific recommendations to get started and to ensure long-term success:

  1. Launch a Pilot Project: Identify one or two OWASP documentation projects to pilot the semantic approach. A good candidate is the OWASP Top 10, due to its popularity and relatively small size (10 items). For example, create a Semantic OWASP Top 10 pilot: use an LLM to parse the Top 10 2021 report into a structured graph (including each risk’s description, CWEs, etc.), and link it to a subset of ASVS requirements and Testing Guide sections. Develop a simple web interface or report from this graph to show how it enhances navigation (e.g., click a Top 10 risk to see related ASVS and Testing Guide info). This pilot will help iron out the ontology and extraction process. Another potential pilot could be with ASVS itself, since ASVS already has structured data – here the focus would be on linking ASVS to other docs and adding context tags. Keep the pilot scope manageable, and show it to OWASP leaders and community for feedback.

  2. Form an OWASP Knowledge Graph Working Group: Assemble interested OWASP leaders, project owners, and volunteers into a working group dedicated to this initiative. This group would steer the ontology design (ensuring it meets all project needs), decide on tools, and coordinate between different documentation projects. Having representation from Top 10, ASVS, Testing Guide, Cheat Sheets, etc., will be important so that the resulting system serves everyone. The working group can also enlist help from semantic web or AI experts in the community (perhaps OWASP members with those skills or even students/academics who want to contribute).

  3. Develop the OWASP Ontology and Schema Collaboratively: As a deliverable of the working group, create a first version of the OWASP ontology/schema. This might be a simple document or data model that lists entity types and relationships. It should be reviewed by the project owners to ensure it captures the essence of their content. Start simple – you can always extend later. For example, define “Risk Category” (with properties: name, description, severity, CWE list) and “Security Requirement” (properties: id, text, level, etc.) and a relation “mitigates”. You might not initially model every nuance (like you might skip “Threat Agent” or other fields from Top 10 if not immediately needed). The key is to have an agreed structure so that different people or tools extracting data will output it consistently.

  4. Create LLM Extraction Playbooks: Document the process for using LLMs to convert an OWASP document into structured form. This includes the prompt design and any post-processing. For instance, write a prompt template for Top 10 items like: “Extract the following fields from this OWASP Top 10 entry: [Name, Description, CWE_IDs, Primary_Mitigations, References]. Use JSON format.” Test this with GPT-4 or similar on one example and refine until it’s giving good output. Then use a script (possibly with OpenAI API) to batch process all items. Do similar for one chapter of the Testing Guide to see how it handles it. The playbook should also cover verification steps – e.g., “After extraction, have someone check that each CWE ID is correct and each reference link is correct.” This semi-automated approach will likely be the way to populate the initial graph.

  5. Integrate with Existing Data Sources: Where structured data exists (ASVS JSON, project CSVs, etc.), write importers to feed those directly into the graph. This ensures accuracy and saves LLM credits for parts that truly need language understanding. Also import known mappings, if any (for example, if OWASP Top 10 already lists “Mapping to ASVS: Vn.n” in its appendix, use that).

  6. Develop a Minimal Useful Application: To demonstrate the utility, build a simple application on top of the emerging knowledge graph. This could be as simple as a “OWASP Graph Search” web page where you select an OWASP Top 10 risk from a dropdown and it shows a list of related ASVS requirements and Testing Guide sections (sourced from the graph). Or a chatbot interface where you can ask, “How do I test for XSS?” and it answers citing the Testing Guide and ASVS. By showcasing even a basic query capability that spans multiple OWASP docs, you will gather support from those who instantly see the time-saving benefit. It doesn’t need to be fancy initially; even a command-line query tool could very useful if it outputs something that previously took an hour of manual searching.

  7. Ensure Open, Machine-Consumable Formats Are Published: As part of this initiative, make it a practice that new versions of OWASP documents come with a machine-readable version. For example, when OWASP Top 10 gets updated, release a JSON file with the content (even if the graph isn’t fully integrated yet). Encourage project leads to use simple formats like YAML/JSON or Markdown with structured fields for any lists or enumerations. The working group can provide templates or tools to help with this. The earlier GitHub issue asking for a JSON version of Top 10 shows community desire; addressing that quickly (even as a static JSON file) is a win on its own.

  8. Community Engagement and Outreach: Communicate progress and involve the wider OWASP community. For instance, present the concept and pilot results in an OWASP Leaders meeting or Global AppSec conference talk. Show a live demo of querying the OWASP knowledge graph. This will excite contributors and maybe attract more volunteers (or even sponsors). You might start an OWASP project formally for the knowledge graph toolset, so it has visibility and an official home. Documentation, of course, should be written to guide users and contributors on how to access and update the graph. By making this an open project, even people outside of OWASP could contribute mappings or improvements (because many security practitioners have interest in such knowledge bases).

  9. Incremental Expansion and Iteration: After a successful pilot, iterate by incorporating more projects. Maybe next bring in the OWASP API Security Top 10, or the Mobile Security Testing Guide, etc. Each addition will likely introduce new entity types or relations (for example, the Mobile projects might add a concept of “Mobile Platform” if they categorize iOS vs Android issues). Grow the ontology and graph accordingly, but maintain coherence. Continuously gather feedback from end-users on what features are most useful. Perhaps the community really wants a feature to compare two OWASP standards side by side – the graph could enable that easily, so build a view for it. Keep iterating with short cycles, adding content and features, rather than disappearing into a year-long development – this ensures the project stays relevant and volunteer momentum remains.

  10. Governance and Upkeep: Long term, decide how this semantic knowledge graph will be maintained. It could be integrated into the workflow of each documentation project (so that when they update the docs, they also update the graph data). Or it could be managed by a central team that monitors all OWASP content updates and updates the graph accordingly. There should be clear ownership to avoid it becoming stale. Perhaps eventually, the knowledge graph becomes the source and the human-readable docs are generated from it – that would be ideal, but it’s a big cultural shift, so it may be a future phase when trust in the system is established. For now, treating the graph as a parallel publication that is updated alongside the main content may work. Also, plan for versioning (e.g., OWASP Top 10 2021 vs 2024 in the graph – likely handled by tagging nodes with version info).

By following these recommendations, OWASP can gradually adopt the semantic model without disrupting ongoing work. The aim is to demonstrate value early (especially to the project leaders whose buy-in is crucial) and to align with OWASP’s ethos of openness and community collaboration. This effort could very well become an OWASP flagship project on its own, showcasing innovation in how security knowledge is shared.

Conclusion

The OWASP community has always been about empowering organizations and developers with knowledge to build secure software. As we move deeper into the digital era, the way knowledge is consumed is changing – it’s more interactive, on-demand, and tailored. To keep pace, OWASP’s own knowledge delivery should evolve from static documents to a dynamic, semantic knowledge graph ecosystem. By doing so, OWASP content becomes more accessible (to both humans and machines), more customizable to diverse needs, and more interconnected for a holistic understanding of application security.

In this paper, we highlighted the current pain points: important OWASP guidelines locked in PDFs and web pages that can’t easily talk to each other or adapt to specific contexts. We then painted a vision of how semantic web technologies and LLMs can transform this situation, turning OWASP’s collective wisdom into a living knowledge graph that is rich with relationships and machine-readable meaning. We drew inspiration from Dinis Cruz’s MyFeeds.ai and Cyber Boardroom projects, which proved that even complex narratives can be distilled into graphs and reassembled into personalized outputs using AI – a blueprint OWASP can follow using open source tools like MGraph-DB and OWASP SBot that are already at our disposal.

The benefits of this shift are immense. Consider a future where a developer in Brazil can query OWASP in Portuguese for the top risks in her fintech web application, and instantly get a curated list with implementation guidance and test checklists drawn from OWASP Top 10, ASVS, and Cheat Sheets – all relevant, up-to-date, and in her language. Or a future where an OWASP Top 10 release isn’t just a PDF, but an interactive data set that companies can import directly into their risk tracking systems, and a knowledge base that AI assistants reference to give developers accurate advice. In such a future, OWASP’s impact would be even greater than it is today, because the knowledge would integrate seamlessly into the workflows and tools developers use.

Importantly, moving to a semantic knowledge graph model keeps OWASP on the cutting edge of how information is shared, ensuring the organization remains the go-to source for application security guidance in a form that modern platforms (and brains) can readily digest. It also reinforces OWASP’s open philosophy: an open knowledge graph is easier for the community to contribute to, remix, and build upon than static docs. The underlying data being open means researchers, educators, and tool builders can create new innovations on top of OWASP content, driving further our mission of spreading security knowledge.

In conclusion, the call to action is clear – by embracing semantic technology and AI-assisted curation, OWASP can overcome current limitations and provide a more powerful, flexible knowledge ecosystem for the next generation of application security challenges. Much of the groundwork has been laid by open source efforts; now it’s up to us in the OWASP leadership and community to take the next step. Let’s pilot this approach, refine it, and gradually roll out an OWASP knowledge graph that will make our projects not just documents to read, but data to query, link, and apply. The result will be an OWASP that not only publishes guidelines, but actively connects the dots of global application security wisdom – driving smarter, faster, and more context-aware security decisions everywhere.

Released under CC BY 4.0. First published on docs.diniscruz.ai; this page as markdown.

← Maturity Models vs. Traditional Standards in Application SecurityThe Future of News Monetization: Embracing Micro and Nano Payments →