Skip to content

"Vulns" should not be surfaced for transitive dependency vulnerabilities #1984

Description

@JoshuaKGoldberg

Surfacing that a (version of) package itself has a reported vulnerability is useful information for end-users. But transitive (deep/nested) vulnerabilities are much more likely to be false positives. False positives from "dumb" audit report mechanisms such as npm audit are a big source of spam in open source (https://overreacted.io/npm-audit-broken-by-design, https://arxiv.org/abs/2601.20240, https://www.joshuakgoldberg.com/blog/please-stop-sending-me-nested-dependency-security-reports if you'll permit my self-post, etc.). For example, in Mocha we receive a few well-intended spam issues every time a new transitive vulnerability is reported (e.g. mochajs/mocha#5779, mochajs/mocha#5780).

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.

Screenshot of the top of https://npmx.dev/package/mocha showing 'Vulns 2'

Activity

  1. changed the title [-]"Vulns" should not be surfaced for transient vulnerabilities[/-] [+]"Vulns" should not be surfaced for transitive dependency vulnerabilities[/+] on Mar 7, 2026
  2. danielroe commented on Mar 7, 2026

    @danielroe
    Member

    this is relevant for me too

    Image

    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

  3. added
    needs discussionAn idea that needs more discussion to understand the scope and impact.
    on Mar 7, 2026
  4. added theissue type on Mar 8, 2026
  5. removed
    staleThis has become stale and may be closed soon
    on Apr 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    needs discussionAn idea that needs more discussion to understand the scope and impact.

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions