Know your blast radius in npm
When a package is compromised, find out who is transitively exposed, whose semver ranges would actually have pulled it, and whether your own lockfile is hit
Compromises are shifting from disclosed CVEs to a single publish
A vulnerability gets an identifier, a patch and a week of lead time. A hijacked maintainer account gets a version number and instant global distribution — every install that resolves the range picks it up within minutes.
Tracking reachability tells you who is actually in range, five levels down, before anyone opens an advisory.
Every bar is one live traversal against the graph running behind this page — no stored figures.
— measured on page load GET /api/blast
Blast radius of real incidents
measuring…Packages transitively exposed to depth 3, measured live. Run the full depth-5 closure
The console for your npm incident response and exposure audit
Answer the five questions an incident actually raises, against one graph and one sidecar, with every figure coming back from a live query.
debug@4.4.2 exposure
How far a compromised package reaches. Shown to depth 3 here; the console walks all five.
Incident
| Package | Depth | Reached via | Dependents | Reach |
|---|---|---|---|---|
| walking the graph… | ||||
Blast radius
Transitive closure from the compromised package out to depth five, drawn as concentric rings and returned as one traversal from a known vertex.
Lockfile
Drop a real package-lock.json and get the exact dependency path that reaches you. Read in the browser, posted once, never stored.
Live feed
Every npm publish as it lands, scored against the graph, so a package thousands already depend on surfaces the moment it moves.
Malware audit
Your whole tree checked against osv.dev, including MAL- identifiers for confirmed malicious packages, with a copy-paste fix.
Separate who is exposed from who was going to install it
Listing a package is not the same as resolving the bad version. Every declared range in the graph is evaluated against the compromised version, so the number you act on is the real one, not the scarier one.
Semver resolution
Which declared ranges would have admitted the bad version
Range resolution
Topology lives in the graph, predicates live in a SQLite sidecar — which is why "would have pulled it" versus "shielded by a pin" is a number this thing can actually produce.
Incident timeline
What the console did for the selected incident, in order
Measured, not claimed
Each step carries the latency the server reported for it, so the timeline is an audit trail of the answer rather than an illustration of one.
See the whole exposed set as one field
Score every npm publish the moment it lands
Is my app affected?
Drop a real package-lock.json. It is read in your browser, posted once, and never stored. The check runs against the incident selected above.
The graph behind it, counted right now
Crawled from the npm registry, reversed into REQUIRED_BY edges and
held in HydraDB with a SQLite sidecar alongside. Reload and the numbers move,
because the crawler is still going.
At this graph size a recursive CTE over the sidecar beats the graph engine by 3–13×, and both return the identical count on every row. That result is in the repository too — including the row that says a 27k-vertex graph does not need a graph database.
— BENCHMARKS.md github.com/Rohit-ATS/blast-radius
Watch exposure compound with every hop
Five registries, right now
Most publishes are somebody's first version with nothing downstream. The ones worth watching are the packages thousands of things already depend on, because that is the moment a supply-chain attack goes live. Every publish below was written into HydraDB as it happened.
Watch your own project and get woken up
Register a lockfile and it becomes a node in the same graph as the packages. When something you install publishes, the alert is routed by traversing from that package to you — not by scanning a subscriber table. Works for npm, PyPI, crates.io, Go and Maven.
Walk the graph yourself
Every node is a real vertex in HydraDB. Click one and the browser asks the database what is adjacent to it — packages, the people who publish them, and the advisories filed against them, all in one graph.
Is anything in my project already malicious?
The check above answers "am I exposed to this incident". This one answers
the question you have before anyone tells you there is an incident — every package
in your lockfile against osv.dev,
including MAL- identifiers for confirmed malicious packages.
The system, right now
Pushed over server-sent events, not polled. This is the same health
check verify.py and chaos.py assert against.
Start measuring your exposure in npm
There is no paid tier and no account. Blast Radius is MIT licensed — clone it, run it against your own registry mirror, lift the semver resolver into your own tooling, ship it inside a commercial product.
MIT License
Every query, every endpoint, the crawler, the benchmarks and this page. One repository, no hosted lock-in.
docker compose up
- Unlimited blast-radius queries
- Unlimited lockfile and OSV scans
- Full JSON API — every panel is an endpoint
- The npm crawler and graph builder
- Semver resolver, reusable on its own
- Benchmark harness against the sidecar
- Commercial use and redistribution
- No telemetry, no account, nothing stored
git clone https://github.com/Rohit-ATS/blast-radius.git