ChainTrace turns your npm and Python lockfiles into one dependency graph, then walks it backwards from any compromised version to the services that actually ship it — with hop counts, the attack path, and a risk score that weighs production first.
npm · bun · pip · poetry · pipenv — lockfile parsed, ranges resolved
from npm:axios@1.7.2
The problem
01Count
A scanner hands you a count of vulnerable packages. Nothing in that list tells you whether the bad version ships in checkout or sits in a test fixture nobody runs.
02Depth
The package that breaks you is three hops down someone else's tree, pulled in by a semver range you never wrote and cannot see from your own manifest.
03Ownership
Risk lands on the service that ships the code, and on the team that owns it. Package-level reports cannot tell you who gets paged tonight.
The approach
Every lockfile becomes vertices and edges in HydraDB, with your services attached to the versions they ship. Ranges are resolved to concrete versions on the way in, so the graph holds what you actually install.
(:Package)-[:HAS_VERSION]->(:Version) (:Version)-[:DEPENDS_ON]->(:Version) (:Service)-[:DEPENDS_ON_VERSION]->(:Version) (:Maintainer)-[:MAINTAINS]->(:Package)
The CLI parses package-lock.json, bun.lock, requirements.txt, poetry.lock and Pipfile.lock, resolves every range to the version the installer would actually pick, and ingests the result. pnpm and yarn lockfiles are detected but not parsed yet. Package coordinates leave your machine; source files never do.
Packages, versions and DEPENDS_ON edges live in HydraDB with the dependency type and the range that pulled them in, npm and PyPI in the same graph. Traversal runs level by level, so you can ask for depth 2 and get depth 2 — not a query that walks your whole graph.
Give it a version key and it walks DEPENDS_ON in reverse, collecting the services that ship it and the number of hops each one sits at. That hop count is the difference between a package you upgrade this quarter and one you page someone for tonight.
A score you cannot audit is a score nobody acts on. Attack paths return the actual chain — service, then each version in between, then the compromised one — with the range that pulled each link in, so you can see exactly where to cut.
Production counts for 60 points, staging for 30. A direct dependency adds 30, one hop adds 20, three or fewer adds 10. Every score arrives with the reasons that produced it, so the ranking is arguable — which is the point.
Who it's for
SECURITY
Sort an advisory feed by which services it actually touches, and close the ones that reach nothing without a meeting about it.
PLATFORM
Every affected service carries its repo, team and environment, so the list of people who need to act writes itself.
ENGINEERING
Hop distance and dependency type tell you which upgrade removes real exposure and which one just moves a number.
How it works
chaintrace scan reads the lockfile, resolves ranges, and writes packages, versions and DEPENDS_ON edges into the graph.
chaintrace scanA service names its repo, team and environment, and the versions it ships. This is what turns a package graph into an impact graph.
POST /servicesHand any version key to blast radius, attack path or risk, and get the services, the chains, and the scores with their reasons.
GET /blast-radiusQuestions
A scanner tells you a vulnerable version is present. ChainTrace tells you which of your services ship it, how many hops away it sits, and what the chain looks like. It answers impact, not presence — and it is meant to sit next to your scanner, taking its findings as input.
For npm: package-lock.json, npm-shrinkwrap.json and bun.lock (including the binary bun.lockb). For Python: requirements.txt, poetry.lock and Pipfile.lock. pnpm-lock.yaml and yarn.lock are detected but not parsed yet. The CLI picks the format out of the project directory, so there is nothing to configure.
Per affected service, out of 100. A production service adds 60, staging 30, anything else 10. A direct dependency adds 30, one hop 20, and three hops or fewer 10. Every score returns the list of reasons that produced it.
Because the questions are all traversals. Reaching backwards from a version to the services that depend on it, at bounded depth, is a graph walk — not a join. HydraDB keeps the graph durable in object storage and reads every query from one pinned snapshot, so a traversal never straddles a write.
Up to five hops per query, and the depth is a parameter. The cap is deliberate: an unbounded walk across a real npm graph is not a query anyone should be able to trigger by accident.
No. The CLI parses the lockfile locally and sends package coordinates — name, version, range — to the ingest API. It does not read or upload source files.
Yes. PyPI packages are ingested from pypi.org, PEP 508 dependency strings are normalised into the same shape as npm's, and everything lands in one graph — keys are prefixed npm: or pypi:. Blast radius, attack paths and risk work the same either way, so a service that ships both is scored across both.
Get started
Start tracing what they reach.
npx chaintrace scan