When a package
is compromised,
what's the blast radius?

Supply chain attacks are surging

BlastRadius computes the complete transitive dependency closure of any npm package in seconds. Powered by HydraDB's graph-native engine — the question a vector database cannot answer.

Source Code →
The problem

Every dependency is a liability.

In 2016, the unpublishing of left-pad broke thousands of projects. In 2024, a compromised ultra package ran malicious code on every install.

The question is always the same: what else is affected? Not just direct dependents — the entire transitive closure. That's a graph traversal problem, and it's what BlastRadius solves.

Three layers

Three layers of risk.

01
BLAST RADIUS

Transitive reverse dependency closure

Every package affected, directly or indirectly, up to 10 hops. Computed via HydraDB's native OpenCypher path procedure — a graph traversal, not a search.

02
SHARED MAINTAINERS

If a maintainer is compromised

Every package they maintain is at risk. Traced through the maintainer graph: package → MAINTAINED_BY → maintainer ← MAINTAINED_BY ← other packages.

03
TYPOSQUAT DETECTION

Packages with similar names

Potential typosquat attacks, ranked by Levenshtein edit distance. Catches left_pad, leftpad, lodas — the packages that trick developers into installing malware.

How it works

A graph traversal, not a search.

HydraDB's native path procedure algo.SSpaths traverses incoming DEPENDS_ON edges from the compromised package, finding every dependent in a single query. Each path returned contains the full chain of nodes and relationships.

// The blast radius query
CALL algo.SSpaths({
sourceNode: $pkgId,
relTypes: ['DEPENDS_ON'],
relDirection: 'incoming',
maxLen: 10,
pathCount: 200
}) YIELD path RETURN path

See the graph explode.

Try es-errors, chalk, or debug to see the full blast radius in seconds.