dependencywatch

How it works

1 · Upload a manifest

Upload package-lock.json, requirements.txt, go.mod or any of the other supported files to a project. The filename matters: we read it to know the format, and we refuse a file whose name we do not recognise rather than guessing at its contents.

2 · We read the versions

Each dependency is recorded with the version your file names and whether that version is exact. A lockfile pins 4.17.20. A package.json says ^4.17.0, which is a range. We store the difference rather than smoothing it over, because everything downstream depends on it.

3 · We compare against published advisories

Advisories come from OSV.dev, which aggregates GitHub Security Advisories, PyPA, RustSec and others and publishes machine-readable affected version ranges. We ask OSV which advisories name each of your packages, and then do the version comparison ourselves — so the page can show you the comparison it made:

You run 4.17.20. The advisory covers 4.0.0 up to but not including 4.17.21, and 4.17.20 is inside that range.

If we asked OSV to do the matching, this page could assert a conclusion it did not reach. That is the posture the product exists to avoid.

4 · You get a weekly digest

Once a week, Monday morning UTC, covering the week that just ended: newly affected packages with the cited range, new unknowns and why, new major versions, and any packages we could not get an answer about. An empty week still sends a digest saying nothing changed — silence is indistinguishable from a broken scanner.

The three answers

There is no fourth, and there is no "probably".

What we cannot tell you →