CHAINBREAK: A Vulnerability Is Never Just a Vulnerability

Avimanyu — Sun, 18 Oct 2026 17:15:02 +0000

A vulnerability scanner tells you that a package is vulnerable.

That's useful. But it leaves an important question unanswered:

What else could that vulnerability affect?

A package might be used by a repository, which is deployed as a service, which supports something critical to a business. The vulnerability itself is only the beginning of the investigation.

A list can tell you what is wrong. Understanding the relationships around that finding helps you investigate where the risk might travel.

That was the idea behind CHAINBREAK, our graph-powered software supply-chain security platform built for Graph Hacks.

We wanted to explore a simple question: what if vulnerability investigation started with connections instead of isolated records?

** Why we chose a graph database**

Software supply chains are networks of dependencies.

A vulnerability affects a package. A package belongs to a software project. A repository is deployed as a service.

Represent those relationships as a graph, and the investigation becomes a traversal:

Vulnerability → Package → Repository → Service

This is why we built CHAINBREAK around FalkorDB.

FalkorDB stores the entities and relationships that power our investigation workflow. Our backend uses Cypher queries to traverse the graph and identify connected packages, repositories, and services.

The graph is not just there to make the interface look interesting. The relationships themselves are central to the product's analysis.

Without those relationships, CHAINBREAK would lose the foundation of its multi-hop impact investigation.

CHAINBREAK currently displays 17 vulnerability records, including a synthetic demonstration vulnerability and advisory records from the OSV ecosystem.

We'll investigate CVE-DEMO-001.

Our demonstration graph contains this path:

CVE-DEMO-001 → log-parser → acme/payment-service → payment-api

Each relationship adds context.

Vulnerability: identifies the finding.
Package: identifies the affected dependency.
Repository: connects that dependency to a software project.
Service: represents a downstream system that could be affected.

Instead of treating these entities as disconnected records, CHAINBREAK follows their relationships in FalkorDB.

This helps demonstrate how graph traversal can reveal a potential blast radius beyond the vulnerable package itself.

One important clarification: the infrastructure path is synthetic demonstration data. It illustrates the investigation workflow; it is not evidence of a real production system or a verified exploit path.

** The query behind the investigation**

The central technical idea is straightforward: start at a vulnerability and follow its relationships.

Here's the Cypher query used for CHAINBREAK's blast-radius investigation:

MATCH (v:Vulnerability {id: $vulnerability_id})
OPTIONAL MATCH (v)-[:AFFECTS]->(p:Package)
OPTIONAL MATCH (p)-[:USED_BY]->(r:Repository)
OPTIONAL MATCH (r)-[:DEPLOYED_IN]->(s:Service)
RETURN v.id AS vulnerability,
v.severity AS severity,
v.title AS title,
collect(DISTINCT p.name) AS packages,
collect(DISTINCT r.name) AS repositories,
collect(DISTINCT s.name) AS services

The query starts with a vulnerability ID, traverses the graph through packages and repositories, and collects the connected services.

The important part isn't the query's length. It's the question it lets us ask:

Given this vulnerability, which entities are connected to it through our modeled software supply chain?

That is where FalkorDB earns its place in the architecture. It allows CHAINBREAK to query the relationships directly instead of relying on a static diagram.

And the result is only as reliable as the underlying data: a graph can reveal modeled connections, but it cannot prove exploitability or real-world impact by itself.

** From investigation to decisions**

Identifying a potential impact path is one part of the problem. The next is deciding what to do.
CHAINBREAK includes a remediation simulator that compares strategies using illustrative risk scores. It also provides an approval workflow for reviewing proposed actions.
These features explore how vulnerability investigation could connect to a more structured decision-making process.

There are limits to the current implementation.

Remediation is simulated; the application does not patch packages or execute changes against production systems. Approval records are stored in application memory and do not persist across backend restarts.

We want to make that distinction clear. A recommendation is not the same as an executed fix, and a simulated workflow is not yet a production remediation system.

The architecture

CHAINBREAK uses a practical stack:
Component Technology Responsibility
Frontend React + Vite Dashboard and investigation interface
Backend Python + FastAPI API endpoints and application logic
Graph database FalkorDB Cloud Graph storage and relationship traversal
Frontend deployment Vercel Hosting the web application
Backend deployment Render Hosting the API

The frontend communicates with FastAPI, which queries FalkorDB for vulnerability information and connected entities.

What building CHAINBREAK taught us

The most important lesson was that a vulnerability record is only one piece of an investigation.

The relationships surrounding it can be equally important. Knowing which package is affected is useful; understanding which repository and service are connected to that package adds another layer of context.

It also clarified why the database choice matters.

In CHAINBREAK, FalkorDB isn't a decorative addition. The product's defining investigation follows graph relationships and traverses them with Cypher. Those relationships are the foundation of the feature we set out to build.

There is still significant work ahead.

A production-ready version would need verified dependency and deployment data, persistent approval storage, and carefully controlled remediation integrations. It would also need to distinguish confirmed relationships from assumptions and communicate uncertainty clearly.

Those are important engineering problems, not details to hide behind a polished interface.

Our goal with this project was to build and deploy a working demonstration of graph-powered vulnerability investigation—and to make the graph central to how the application works.

The idea behind CHAINBREAK

We started with a simple question:

What if vulnerability investigation didn't stop at the package?

CHAINBREAK connects vulnerabilities, packages, repositories, and services in FalkorDB, then traverses those relationships to investigate potential downstream impact.

It doesn't solve software supply-chain security, and it doesn't claim that every modeled path represents a real exploit. It demonstrates a way to investigate vulnerabilities through the relationships around them.

Don't just find the vulnerability. Follow the connections. Understand the potential impact.

That is CHAINBREAK.

Try CHAINBREAK

Live demo: https://chainbreak-orpin.vercel.app/
Source code: https://github.com/engineerkrish/CHAINBREAK
API documentation: https://chainbreak-sn2d.onrender.com/docs

Built for Graph Hacks using FalkorDB.
AI coding assistance was used during project development.

DEV Community: Avimanyu

CHAINBREAK: A Vulnerability Is Never Just a Vulnerability