DEV Community: Kaustubh_Negi

BlastRadius: Why Severity Scores Lie, and How Graph AI Solves Real Attack Paths

Kaustubh_Negi — Sat, 17 Oct 2026 18:28:55 +0000

"Defenders think in lists. Attackers think in graphs. As long as this is true, attackers win."
— John Lambert, Distinguished Engineer, Microsoft Threat Intelligence

The 2:00 AM Alert Delusion

It is 2:14 AM. Your security scanner finishes sweeping your hybrid cloud infrastructure and drops a fresh spreadsheet into your ticketing queue: 4,821 open vulnerabilities.

Two hundred of them are flagged with a CVSS 9.8 or 10.0 Critical.

Your SecOps team has the engineering bandwidth to patch roughly ten servers this sprint. How do you choose?

If you do what 95% of security teams do, you sort the column by CVSS descending and start patching from the top:

legacy-ftp: CVSS 10.0 (Log4j remote code execution).
batch-legacy: CVSS 9.8 (CGI deserialization exploit).

Congratulations: your team spent 36 uninterrupted engineering hours patching two isolated, legacy servers sitting on an air-gapped staging subnet with zero egress and zero access to customer data.

Meanwhile, an unpatched CVSS 7.5 OpenSSL bug on your internet-facing api-gateway sat at ticket #384 in your backlog. Six hours later, an adversary used that single gateway to pivot into your microservices mesh and exfiltrate your entire customer database in three hops.

[The Vulnerability Mirage]

Isolated Subnet:
  [Attacker] ──x──> [legacy-ftp (CVSS 10.0)] ──x──> (DEAD END)

Production Route:
  [Attacker] ─────> [api-gateway (CVSS 7.5)] ─────> [db-customers (PII)]
                    ▲
                    └── THE REAL ATTACK PATH

Severity scores tell you how dangerous a vulnerability is in isolation. They tell you nothing about whether an adversary can actually reach your crown jewels.

We built BlastRadius to invert this paradigm: a graph-native, autonomous AI agent powered by FalkorDB and the Model Context Protocol (MCP) that maps true network reachability, calculates topological choke points, and safely remediates attack paths without taking down production.

Live Interactive Demo: https://blastradius-ashy.vercel.app
GitHub Repository: https://github.com/saksham-2x7/BlastRadius_V1
Youtube Demo Link: https://youtu.be/IauSZKEO8PQ

1. The Relational Trap vs. The Graph Reality

Why hasn't the cybersecurity industry solved this already? Because answering the fundamental question—"Can an attacker on the public internet walk from an exposed ingress point to our customer database through exploitable vulnerabilities?"—is computationally agonizing in relational databases.

The Relational Nightmare (SQL)

To trace lateral movement across a dynamic cloud network in a relational database, you must execute recursive Common Table Expressions (WITH RECURSIVE) across five separate tables: hosts, network_interfaces, firewall_rules, installed_services, and cve_vulnerabilities.

At 4 hops, relational engines devolve into massive Cartesian joins that bring relational query planners to their knees.

The Vector Search Fallacy (Naive LLMs)

Many modern "AI security tools" attempt to dump scan reports into vector databases (RAG) and prompt an LLM: "Find the attack path."
This fails disastrously. Vector distance is not topological connectivity. LLMs cannot reliably trace multi-hop network paths in natural language; they hallucinate hops through air-gapped subnets, fabricate firewall allowances, and skip critical lateral constraints.

The FalkorDB Solution

In FalkorDB, network infrastructure is represented in its natural state: a directed property graph.

Because FalkorDB is built on sparse matrix linear algebra (GraphBLAS) running over the ultra-fast Redis wire protocol, variable-length path traversal is not a pointer-chasing crawl—it is an optimized linear algebraic matrix multiplication executed in microseconds.

Finding all paths from the public internet to our crown jewel database is a single OpenCypher query:

MATCH path = (entry:InternetEntry)-[:EXPLOITABLE_ROUTE*1..5]->(target:CrownJewel {name: 'db-customers'})
RETURN path, length(path) AS hops

[Public Internet]
       │
       ├──> [edge-apache] ──> [api-gateway] ──┐
       ├──> [edge-nginx]  ──> [api-gateway] ──┼──> [db-customers] (CROWN JEWEL)
       ├──> [edge-node]   ──> [api-gateway] ──┘
       └──> [edge-apache] ──> [worker-java]  ─────> [db-customers]

One query. Instant topological reality. FalkorDB identifies the exact four attack routes an adversary can execute today.

2. Real Telemetry: Why CVSS and EPSS Mislead in Isolation

To reflect real enterprise environments, BlastRadius ingests live vulnerability telemetry:

CVSS (Common Vulnerability Scoring System): Theoretical baseline severity.
FIRST EPSS (Exploit Prediction Scoring System): Machine-learning exploit probability based on in-the-wild threat telemetry.
CISA KEV (Known Exploited Vulnerabilities): Authoritative catalog of CVEs actively leveraged in active campaigns.

Look at how raw scores compare to graph-grounded reality in our testbed:

Server Host	Role	Primary Vulnerability	CVSS	EPSS / KEV	Graph Attack Paths	True Threat Status
`legacy-ftp`	Deprecated Storage	Log4j (CVE-2021-44228)	10.0	High (KEV)	0	Noise (No route to crown jewels)
`batch-legacy`	Internal Batch Job	CGI RCE (CVE-2014-6271)	9.8	Moderate	0	Noise (Dead-end subnet)
`api-gateway`	Microservice Ingress	OpenSSL (CVE-2022-3602)	7.5	Low	3 of 4	CRITICAL CHOKE POINT

If you follow traditional security advice, you spend your week patching legacy-ftp and batch-legacy. Your customer database remains completely exposed.

BlastRadius immediately surfaces that patching a single CVE on api-gateway eliminates 75% of your total attack surface in one stroke.

3. The Agent Mind: Parameterized MCP, Not Hallucinated Cypher

A common anti-pattern in generative AI projects is "Text-to-SQL" or "Text-to-Cypher," where the LLM is asked to write raw queries against production databases.

In cybersecurity, this is unacceptable:

Hallucination Risk: The LLM invents relationship labels or filter predicates.
Denial of Service: An unconstrained, Cartesian query can lock up database memory.
Security Injection: Prompt injection could manipulate the Cypher string to leak sensitive topology.

BlastRadius uses the Model Context Protocol (MCP). The LLM agent never writes raw Cypher. Instead, it interacts with FalkorDB through deterministic, strongly-typed MCP tools:

┌─────────────────┐       MCP Request       ┌──────────────────┐
│                 │ ──────────────────────> │                  │
│    AI Agent     │                         │  FalkorDB Engine │
│ (Reasoning Core)│ <────────────────────── │ (Ground Truth)   │
└─────────────────┘       Typed Subgraph    └──────────────────┘

The Core MCP Toolset:

find_choke_points(): Runs FalkorDB's betweenness centrality algorithms to mathematically score nodes that funnel the highest percentage of attack traffic.
get_shortest_attack_path(source, target): Executes FalkorDB's native shortest-path traversal to calculate minimum attacker effort.
simulate_remediation(target_node): Clones the active subgraph in memory, simulates patching or isolating the node, and recalculates remaining attack paths.
apply_remediation(target_node): Commits changes to the live graph and updates state.
draft_jira_ticket(finding): Formats an engineering ticket containing exact reproduction paths, affected assets, and rollback plans.

Handling the 4-Way Shortest Path Tie

When an operator asks: "Show the shortest route an attacker could take", real-world networks often feature symmetric microservice ingress paths.

In our reference architecture, FalkorDB evaluates all possible attack routes and detects a four-way tie, each requiring exactly 3 hops:

internet → edge-apache → api-gateway → db-customers
internet → edge-nginx → api-gateway → db-customers
internet → edge-node → api-gateway → db-customers
internet → edge-apache → worker-java → db-customers

Rather than arbitrarily picking one route or truncating results, BlastRadius highlights all four tied paths across our React Flow topology canvas simultaneously. Operators immediately grasp the redundancy of the adversary's options.

4. The Breakthrough: Graph-Governed Autonomy Tiers

The biggest obstacle to AI agents in infrastructure is trust. Nobody wants an autonomous agent making blind changes to production services.

Most AI projects attempt to enforce safety through system prompts:

"You are a helpful assistant. Please do not modify critical servers without asking."

This is dangerous. LLM system prompts can be bypassed, misunderstood, or ignored under complex context windows.

In BlastRadius, the graph enforces safety, not the AI prompt.

                  [User: "Fix everything safe"]
                                │
                                ▼
                   [Agent: Inspect Node Tier]
                                │
               ┌────────────────┴────────────────┐
               ▼                                 ▼
      [Tier 1: Leaf Worker]             [Tier 3: Choke Point]
    (Low Betweenness Centrality)       (High Centrality / Ingress)
               │                                 │
               ▼                                 ▼
       Simulate in FalkorDB              REFUSE TO MODIFY
               │                                 │
               ▼                                 ▼
         Apply Patch                     Draft Jira Ticket with
       (Paths Drop: 4 → 1)               Rollback & Graph Proof

How Autonomy Tiers Are Computed:

Before touching any node, the MCP server calculates the node's Autonomy Tier directly from FalkorDB metrics:

Tier 1 (Safe Autonomous Remediation): Low betweenness centrality, non-ingress role, zero downstream production dependencies. The agent simulates the fix, verifies the path reduction, and executes the patch autonomously.
Tier 3 (Human-in-the-Loop Guardrail): High betweenness centrality, ingress gateway, or shared routing component.

When the operator types: "Fix everything that is safe", the agent patches the edge servers autonomously—dropping attack paths from 4 down to 1.

But when it encounters api-gateway, it explicitly refuses.

The agent informs the operator:

"Remediation refused for api-gateway. This node has high topological centrality and serves active ingress routes. Severing or modifying this node without maintenance coordination risks dropping production traffic. I have drafted Jira ticket SEC-402 with full graph evidence, affected paths, and a rollback plan for human approval."

The model did not decide this out of caution; the graph topology mathematically forbade it.

5. Epistemic Memory: Storing Reasoning in the Graph

Traditional chatbot agents suffer from stateless amnesia. If you return to the console three days later and ask: "Why didn't you patch the API gateway on Tuesday?", a typical agent has no idea what you're talking about.

BlastRadius writes its actions, simulations, and refusals back into FalkorDB as first-class graph entities:

CREATE (d:AgentDecision {
    action: 'REMEDIATION_REFUSED',
    target: 'api-gateway',
    reason: 'HIGH_BETWEENNESS_CHOKE_POINT',
    risk_score: 0.89,
    timestamp: 1729208000
})-[:EVALUATED_AGAINST]->(h:Host {name: 'api-gateway'})

Because reasoning is stored natively in the graph:

Auditability: Security teams can query historical decisions via Cypher.
Explainability: Every action has a bi-directional edge to the exact topological state that triggered it.
Multi-Session Continuity: Any operator on the team can inspect past decisions instantly.

6. Multi-Tenancy & Bringing Your Own Data

Enterprise security tools cannot be toy prototypes with hardcoded data.

BlastRadius allows teams to click Use your own data, upload network inventory or vulnerability scans, and instantly instantiate a private, isolated graph.

Because FalkorDB handles multi-tenant graph namespaces with zero overhead, each user or organization operates within a strictly partitioned graph space—allowing rapid scan-to-graph conversion without infrastructure friction.

7. The Technical Stack

Live Application: Deployed on Vercel
Graph Engine: FalkorDB (GraphBLAS-powered sparse matrix OpenCypher engine)
Backend: FastAPI (Python 3.12) deployed on Railway
Protocol: Model Context Protocol (MCP) servers exposing deterministic graph primitives
Visual Frontend: React Flow dynamic canvas rendering live attack paths, choke point halos, and edge transitions
Continuous Integration: GitHub Actions CI test suite verifying Cypher traversal accuracy, shortest-path calculation, and autonomy tier enforcement against a real, running FalkorDB container

Why BlastRadius Wins

Most security tooling generates more data, more alerts, and more cognitive fatigue.

BlastRadius does the opposite:

It ignores isolated high-CVSS distractions.
It pinpoints the exact topological choke point using FalkorDB graph algorithms.
It proves why the choke point matters with live multi-path tracing.
It executes safe remediations autonomously while enforcing rock-solid, graph-computed guardrails on critical infrastructure.

Attackers will always think in graphs. It’s time our defenses did too.

Live Demo: https://blastradius-ashy.vercel.app
GitHub Repository: https://github.com/saksham-2x7/BlastRadius_V1
Youtube Demo Link: https://youtu.be/IauSZKEO8PQ

No pip install? No problem. Building RepoXray with Python's Standard Library

Kaustubh_Negi — Thu, 03 Sep 2026 16:46:34 +0000

What happens when you want to build a codebase analyzer, and your first instinct is to install a library for everything?

You install a package for CLI handling.

Another for parsing.
Another for graphs.
Another for searching.

And suddenly your “zero-dependency” project has... a lot of dependencies. 😭

For the Zero Dependency Hackathon, our team decided to build RepoXray, a command-line tool for understanding unfamiliar codebases.

The catch?

We couldn't use third-party runtime dependencies.

So instead of asking “Which package should we use?”, we had to start asking:

“What do we actually need, and can Python's standard library give us enough to build it ourselves?”

That turned out to be the interesting part.

What is RepoXray?

When you open an unfamiliar repository, you usually want answers to a few basic questions:

What is this project?
Where is the important code?
What depends on what?
Which files use this one?
If I change something here, what might break?

RepoXray tries to answer those questions from the command line.

Its workflow is:

SCAN → INDEX → RESOLVE → ANALYZE → ANSWER

It scans a repository, builds a local index, searches its contents, inspects files, resolves local relationships, and performs dependency and impact analysis.

The idea isn't to replace an IDE or a full language server.

It's to make exploring an unfamiliar codebase faster and more structured.

Then the package manager disappeared

This was the part that changed how we approached the project.

Normally, reaching for an existing library is often the sensible engineering decision.

Need graph traversal? There are libraries for that.
Need parsing? There are libraries for that too.

But the hackathon constraint meant we had to build around what Python already provides.

Some of the pieces we ended up using were:

argparse → command-line parsing
pathlib / os → filesystem operations
ast → Python analysis
re → pattern matching
hashlib → file fingerprints
json → persistent index data
collections → graph/data structures
sqlite3 → database inspection
zipfile → archive inspection
unittest → testing

We documented 11 meaningful standard-library substitutions in our STDLIB log.

But the interesting part wasn't finding a one-to-one replacement for every package.

It was deciding how much functionality we actually needed.

The hardest part wasn't scanning files

Walking through a repository and calculating a SHA-256 hash isn't particularly difficult.

Building a useful index around that information is.

We had to handle things like:

added and deleted files
modified files
renamed files
empty projects
corrupt indexes
unchanged files that should be reused

That led to incremental indexing, where unchanged information can be reused instead of rebuilding everything from scratch.

The standard library gave us the building blocks.
The actual behavior was ours to design.
Import resolution: don't turn guesses into facts
Another interesting problem was figuring out which files depend on which.

For Python and JavaScript/TypeScript projects, imports aren't always straightforward file paths.

There can be relative imports, different extensions, ambiguous candidates, and imports that aren't repository-local at all.

So RepoXray doesn't pretend every relationship is certain.

It distinguishes between:
Resolved
Heuristic
Ambiguous
Unresolved

That was a deliberate choice.

A tool that confidently gives you the wrong dependency graph is worse than one that admits when it isn't sure.

Once those relationships exist, we can ask higher-level questions:

python3 repoxray.py depends-on repoxray.py .
python3 repoxray.py who-uses repoxray.py .
python3 repoxray.py impact repoxray.py .

So instead of simply searching for text, RepoXray can reason about repository relationships.

What would we normally install?

This is where the “Package Killer” idea becomes interesting, even though RepoXray itself isn't a replacement for one specific package.

For graph-related functionality, for example, NetworkX would be an obvious library to consider.

But we didn't recreate NetworkX.
We didn't need all of NetworkX.

We needed a smaller set of graph operations for our specific problem, so we implemented those ourselves using standard-library data structures and traversal logic.

The same principle applied throughout the project.

We weren't trying to rebuild the Python ecosystem.

We were trying to build the functionality our application actually needed without depending on it.

Then we tried to break it

A demo can show that your program works once.

Tests tell you what happens when someone tries to ruin your day. 😭

Our test suite covers cases including:

empty projects
malformed and corrupt indexes
ambiguous imports
relative imports
JavaScript imports
cycles and self-references
deep traversals
incremental changes
large-file searching
Unicode and spaces in paths

The full suite finished with:

Ran 21 tests in 5.960s

We also checked that RepoXray could import with Python's site-packages disabled:

python3 -S -c "import repoxray; print('stdlib import check passed')"

Result:

stdlib import check passed

And we packaged the application as a Python zipapp:

python3 build.py

producing:

dist/repoxray.pyz

The artifact could then be executed directly with:

python3 dist/repoxray.pyz --help
What I actually learned

The biggest surprise was that zero-dependency development isn't really about avoiding imports.

It's about understanding what those imports are buying you.

The standard library already gives Python a lot:

filesystems, hashing, parsing, data structures, serialization, databases, archives, testing, and more.

But none of those things magically becomes a codebase analyzer.

The engineering happens in the layer where those pieces are combined into something useful.

That was probably the best part of the constraint.

It forced us to stop asking:

“What package does this problem have?”

and start asking:

“What is the actual problem we're solving?”

Sometimes the answer was a few standard-library calls.

Sometimes it was significantly more code.

And sometimes the right answer was simply to accept a limitation instead of trying to recreate an entire ecosystem.

Final thoughts

RepoXray isn't trying to prove that third-party packages are bad.

They're not.

Packages exist for a reason, and rebuilding mature libraries from scratch is usually not a good use of engineering time.

The interesting thing about this hackathon was being forced to operate without that safety net.

We ended up building a codebase analyzer with repository scanning, indexing, search, import resolution, dependency relationships, impact analysis, testing, and a runnable zipapp, all while keeping the runtime dependency-free.

And somewhere along the way, a simple restriction turned into one of the more useful engineering exercises we've done.

Not:

“How do we avoid using packages?”

But:

“What can we actually build with what we already have?”

For a first-year student team, that's a question I'm pretty happy we got to explore.

And yes, I'm still signing up for more hackathons.

Apparently I learn slowly. 😭

RepoXray: https://github.com/saksham-2x7/repoxray

What package would you normally reach for when building something like this? 👀

So... what happens when a first-year student decides to take hackathons seriously?

Kaustubh_Negi — Tue, 01 Sep 2026 15:31:34 +0000

Probably sleep deprivation. Definitely Git commits. And somehow, three projects later, I'm still here. 👀

I'm a first-year B.Tech CSE (AI-ML) student at Yenepoya School of Engineering & Technology, Bengaluru, and part of the Kalvium program.

I've been getting increasingly interested in AI/ML, software development, developer tools, and building things that actually do something. And recently, I've found hackathons to be one of the fastest ways to turn "I think I could build this" into "wait... it's actually running." 🚀

Over the last few months, I've had the chance to work on a few projects:

🏢 DayFlow

An HRM system built for the Odoo × NMIT Hackathon, where we explored how an intelligent workforce management system could bring different HR workflows together.

📱 L.A.S.A.

A Local AI Smartphone Assistant for the iQOO × ReSkill Hackathon, exploring how AI could become a more natural part of the smartphone experience rather than another app you have to open.

🔎 RepoXray

A zero-third-party-runtime-dependency codebase analyzer built for the Zero Dependency Hackathon.

This one was particularly interesting because we had to build the entire thing using Python's standard library. No installing a convenient package whenever something got annoying. 😭

And apparently three hackathons weren't enough, because I'm currently taking part in PromptWars and an AI Innovation Hackathon with a six-member team.

I'm still very much at the beginning of this journey, so I'm not here pretending I have everything figured out.

I'm here to build, break, learn, document the process, and hopefully make the next project slightly less chaotic than the previous one.

This is my first post on DEV, so here's to whatever comes next. 🥂

What was the first project that made you feel like, "Okay, I'm actually building software now"?