What we cannot tell you

A page of its own, linked from the header, because the thing that makes this product worth using is what it refuses to claim.

Whether your code actually calls the vulnerable function

This is called reachability analysis and we do not do it. A finding here means your installed version is inside the advisory's published range and nothing more. Plenty of true findings are not exploitable in your application, and we have no way to tell you which.

Which version a range would install

We could ask npm what ^4.17.0 resolves to today and print a confident badge. It would be right until your next install and we would have no way to know when it stopped being right. So we answer unknown and tell you the lockfile would settle it.

Whether an upgrade will break your build

We can tell you the maintainer published a new major version, which under the semver contract they publish under means they intend a breaking change. Whether that break touches anything you call is not knowable from here. We have not read the changelog for you.

When an npm version was published

For PyPI we show the release date, because PyPI publishes it. For npm we do not, and the row simply has no date on it. The cheap npm document carries a last modified timestamp for the whole package — which moves when a patch lands on an old branch, or a maintainer edits something — and printing that under a version number would be a date that is usually near enough to look right and is not the answer to the question. The document that does hold the real date is several megabytes per package. We would rather show you no date than a plausible one.

Anything about four ecosystems, with confidence

We order versions for npm, PyPI, Go and crates.io. For RubyGems, Packagist, Maven and NuGet we list your dependencies and show the advisories that name them, but range-based findings come back as unknown — we have not written and tested a version comparator for those ecosystems, and a wrong ordering would produce a confident wrong answer. An advisory with an enumerated list of affected versions still resolves, because that needs string equality rather than ordering.

Anything about a package OSV has never heard of

Advisories come from OSV.dev and are only as complete as OSV is. A private registry, a vendored library or an advisory published nowhere machine-readable is invisible to this product.

That a package is clean when we could not reach the database

When a scan cannot get an answer for some packages, those packages are listed by name as unchecked — on the project page and in the weekly digest. They are never folded into a clean result.

Anything at all via a language model

Every verdict on this site is version arithmetic. A model is used for one optional thing: rewriting an advisory's own description into plainer English when you ask for it. That text is checked before you see it, and discarded if it names a version the advisory does not contain, makes any claim about whether you are affected, or recommends an upgrade target. When it is discarded you are told, and you get the advisory's own words.