VulnSwarm: The Security Scanner That Thinks in Graphs
It turns source code into a Neo4j-backed attack map, then uses reachability, centrality, and agentic review to find the code paths that matter most.
- VulnSwarm is interesting because it treats security as a graph problem first and an LLM problem second.
- Its real novelty is not pattern matching, but ranking the code paths whose structure gives a bug the biggest blast radius.
- The pipeline uses Joern and Neo4j to turn source into a queryable attack map before any agent starts reasoning.
- The agent layer matters most when it is constrained by graph-backed findings, not when it is asked to inspect an entire repo blindly.
Most scanners ask a narrow question: does a known bad pattern appear here? VulnSwarm asks a harder one: where in this codebase would a mistake matter most? That shift changes the job from pattern matching to structural risk analysis.
That is why the project’s most interesting idea is not the LLM. It is the graph. VulnSwarm turns code into a network of functions, calls, and flows, then uses that network to find chokepoints, reachability, and sinks that deserve scrutiny.
Why VulnSwarm Starts With a Graph
The repo’s architecture makes its thesis clear. Source code is parsed with Joern, normalized into a custom schema, stored in Neo4j, and then analyzed with graph algorithms like reachability and betweenness centrality. In other words, the scanner does not begin with text. It begins with structure.
This matters because a graph changes the security question. A flat scan looks for a source to sink path. A graph can also ask which nodes sit on many paths, which nodes connect otherwise separate regions, and which nodes would make an exploit chain much easier to build.
Reachability Finds the Obvious Paths. Centrality Finds the Dangerous Ones.
VulnSwarm’s analysis stage combines two different lenses. First, it walks the graph from entry points to see what is reachable. Then it scores the intermediate nodes with betweenness centrality, which is a useful proxy for chokepoints. A function that sits between many flows is not automatically vulnerable, but it is a place where one bug can spread farther than a local linter would suggest.
The repo’s own implementation backs that up. The analysis module uses BFS for reachability and NetworkX betweenness centrality for structural importance. Sink classification then applies profile hints, so the same engine can flag different risky APIs depending on language or environment.
| Layer | Semgrep | Nuclei | Burp-style DAST | VulnSwarm |
|---|---|---|---|---|
| Core unit | Pattern | Template | Runtime behavior | Graph structure |
| What it catches well | Known code smells fast | Known external attack surfaces | Live request and response issues | Reachability, chokepoints, exploit chains |
| What it misses | Cross-file structural risk | Deep code reasoning | Static architecture flaws | Simple template-only coverage |
| Operational shape | Lightweight and fast | Fast and broad | Interactive and manual | Heavier, but deeper |
| Main trade-off | Shallow context | Template dependence | Runtime scope only | Infrastructure cost for better structural insight |
That comparison is the important one. VulnSwarm is not trying to replace Semgrep or Burp. It is trying to sit between them, as a reasoning layer that makes codebase structure first-class.
The Profile System Makes the Scanner Portable
Profiles are what keep the approach from hardcoding one security worldview. A profile defines what counts as a source, sink, or risky pattern, so the same graph machinery can adapt across Python, JavaScript, or Go without rewriting the analysis engine.
The core issue is that static analysis tools flag the obvious vulns (SQLi, hardcoded secrets) but miss the architectural ones — like an AI coding agent that generates a perfectly valid authentication flow but chooses the session token storage strategy that happens to be vulnerable to a specific timing attack the tool wasn't trained on.
That quote captures the project’s premise well. VulnSwarm is not chasing only obvious sinks like `eval` or `system`. It is looking for the architectural cases where a bug is not loud, but dangerous because of where it sits in the graph.
The Agentic Layer Is the Second Act
The orchestration layer is designed like a small team. There is an orchestrator, analyzers, verifiers, and chain builders. The point is not to let the model freestyle over the whole repository. It is to feed graph-backed findings into focused agents that can trace exploit chains, challenge false positives, and explain why a path matters.
That is the right place for an LLM. Once the codebase has been reduced to a security graph, the model can do what it is good at: connect evidence, compare paths, and reason adversarially about plausible chains. Without the graph, the model is guessing. With it, the model is reviewing.
What VulnSwarm Is Really Competing Against
The competition is not another AI toy. It is a different class of tool. Semgrep gives you fast pattern detection. Nuclei gives you template-driven coverage. Burp-style tools give you runtime verification. VulnSwarm tries to understand structural risk across a codebase, then hand that structure to agents that can reason about chains instead of isolated findings.
| Tool | Best for | Blind spot | Why VulnSwarm differs |
|---|---|---|---|
| Semgrep | Fast static pattern checks | Cross-file blast radius | It models the codebase as a graph, then scores the paths |
| Nuclei | Broad template coverage | Deep source-code context | It reasons about the application, not just the endpoint |
| Burp Suite | Interactive runtime testing | Static architecture and code structure | It starts before traffic exists, at the level of code relationships |
| VulnSwarm | Structural security analysis | Maturity and infrastructure cost | It tries to surface the nodes that make exploits easier to build |
That framing is honest. VulnSwarm is early, and some of its agent phases are still stubbed. It also leans on heavyweight tooling like Joern and Neo4j. But those trade-offs are consistent with the thesis: if you want deeper analysis, you pay for a deeper model of the code.
The Trade-Offs
The upside of this design is precision about where to look. The downside is operational complexity. Joern setup, graph persistence, and multi-agent orchestration are not lightweight. But that complexity buys the scanner something simpler tools cannot: the ability to ask which parts of a codebase are structurally critical before a human starts chasing a bug report.
VulnSwarm is a multi-agent AI framework that scans your codebase and local web apps for vulnerabilities, then tells you exactly how to fix them. It mirrors a real pen test team with specialized agents for recon, exploitation analysis, red teaming, and remediation.
That is the right ambition for this repo. It is not a generic assistant, and it is not a shallow scanner with a chat box bolted on. It is an attempt to make security feel like graph reasoning, then use LLMs to review the graph with a sharper eye.