You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
"Vulns" should not be surfaced for transitive dependency vulnerabilities #1984
Without a way for packages to register themselves as unaffected, having that big angry Vulns indicator on the package makes it seem like the transitive vulnerabilities impact the package. I'd really prefer for the newer better npmjs to not contribute to this common misperception that transitive vulnerabilities are by nature relevant vulnerabilities. A lot of devs will look at a package registry page, see a bad text+number combo, and not read any further.
Vague straw man starting proposal: how about adding a toggle to Vulns about whether to count transitive dependencies? It can be off-by-default and have informative text about false reports attached to it, to help make sure folks only get that info if they've been informed about its downsides.
changed the title [-]"Vulns" should not be surfaced for transient vulnerabilities[/-][+]"Vulns" should not be surfaced for transitive dependency vulnerabilities[/+]on Mar 7, 2026
nevertheless, exposing this info is I think useful, but obviously people have to understand what to do with the information. they also don't understand that (even real) vulnerabilities in a dep tree aren't something to fix in a top-level package.
... added to which there are so many false vulnerabilities (like redos attacks for dev-time dependencies, for example)
but this is a problem with the state of vulnerability info... and shouldn't necessarily be solved by hiding the vuln.
we could possibly add a little note in the vuln info box that helps educate people in what are real vulns, and how to evaluate a report from OSV
Activity
[-]"Vulns" should not be surfaced for transient vulnerabilities[/-][+]"Vulns" should not be surfaced for transitive dependency vulnerabilities[/+]danielroe commentedon Mar 7, 2026
this is relevant for me too
nevertheless, exposing this info is I think useful, but obviously people have to understand what to do with the information. they also don't understand that (even real) vulnerabilities in a dep tree aren't something to fix in a top-level package.
... added to which there are so many false vulnerabilities (like redos attacks for dev-time dependencies, for example)
but this is a problem with the state of vulnerability info... and shouldn't necessarily be solved by hiding the vuln.
we could possibly add a little note in the vuln info box that helps educate people in what are real vulns, and how to evaluate a report from OSV