AI
Security Tools Generate Alerts Without Proof
Security teams deploy SAST, DAST, and SCA tools and end up with thousands of alerts. Those alerts flag patterns. They do not prove exploitability. Developers get flooded, lose trust, and push back with one question: how is this actually exploitable? Without an answer, engineers focus only on findings labeled critical by the tool itself, whether or not that label reflects real risk. A low or medium finding could rank higher given other context. The context just isn’t there.
What Chaining Findings Actually Proves
The log4j example makes the point. SCA flags an outdated library. SAST flags the vulnerable function called in the worst possible way. DAST shows the code maps to a publicly accessible endpoint with a request-response payload. Each tool sees one piece. None connects them. If a security engineer could read all three together, the severity is obvious. If log4j is behind a feature flag and never reachable, the risk drops. Deployment context changes everything, and today no tool captures that automatically.
Why VXDF Required Its Own Schema
Shah consulted contributors from CycloneDX and OCSF before building VXDF’s schema. OCSF (Open Cybersecurity Schema Framework) handles telemetry and SIEM events well. It falls short on code flow analysis and static analysis enrichment. Retrofitting it requires so many extensions that you end up writing a new schema anyway. CycloneDX covers SBOM but not exploit data flows. The industry had no standard for serializing cross-tool finding chains. VXDF fills that gap: a schema built specifically for what the engine needs to do.
The VXDF Engine: Ingestion and Graph Construction
The engine takes three inputs: SARIF files from static analysis, CycloneDX SBOMs, and ZAP JSON from DAST. A normalization layer assigns canonical IDs to services, components, and vulnerabilities across all three formats. This deduplicates findings that appear in multiple tools. The schema enforces causality: a service can only depend on a component, so the engine builds a Neo4j knowledge graph with deterministic relationships. Querying that graph with breadth-first traversal gives a security engineer a readable story: which service, which component, which vulnerability, where it is exposed.
Graph RAG Turns a Question into an Evidence Pack
A LoRA model converts a plain-English query (“is CVE exploitable today?”) into a Cypher plan template. That template executes against the Neo4j graph and returns a subgraph Shah calls the evidence pack. The evidence pack shows the service, its component, the vulnerability, which tools flagged it, the provenance of each alert, and the request-response payload if DAST confirmed it. The engine computes an exploitability score and a rationale. The output is a VXDF JSON file that LLMs can eventually interpret directly.
Notable Quotes
They don’t detect findings. They don’t detect proof. Mihir Shah · ▶ 2:28
That is when I bump the severity. Mihir Shah · ▶ 12:35
evidence pack is the gold, right? Mihir Shah · ▶ 20:28
Key Takeaways
- SAST, DAST, and SCA each see one piece of a vulnerability; none connect them automatically.
- Deployment context (EC2 vs. GKE, feature flag, public endpoint) determines actual severity more than the tool’s label.
- VXDF normalizes findings from SARIF, CycloneDX, and ZAP into a Neo4j graph with schema-enforced causality.
- GraphRAG with a LoRA model converts natural-language questions into Cypher queries that return a ranked evidence pack.
- The project is actively seeking volunteers; weekly calls run Tuesdays at 8 a.m. Pacific.
About the Speaker(s)
Mihir Shah is a contributor in cloud-native and application and cloud security space. He is the author of the Cloud Native Software Security Handbook. As the leader of OWASP’s VXDF Project, Mihir champions open-source solutions for automated threat modeling and vulnerability assessment.