Please Stop Sending Me Nested Dependency Security Reports

As an open source maintainer, I regularly receive “critical security vulnerability” DMs, emails, and GitHub issues about my projects. Most of these notices are sent from individual developers or IT teams about packages that are dependencies of dependencies. These “nested dependency” reports often go something like:

Hello. We use your-package and npm audit is reporting a critical issue:

some-nested-dependency  <=0.1.2
Severity: critical
Prototype Pollution in some-nested-dependency - https://github.com/advisories/GHSA-ab12-cd23-ef45
No fix available
node_modules/some-dependency/node_modules/some-nested-dependency
  some-dependency  >=2.3.4
  Depends on vulnerable versions of some-nested-dependency
  node_modules/some-dependency
    your-package  >=5.6.7
    Depends on vulnerable versions of some-dependency
    node_modules/your-package

Could you please fix this?

I appreciate the attention to detail and security. Really, I do! Paying attention to your tooling is a useful skill for any developer.

But these reports aren’t useful. They don’t come with the context and proof-of-concept a real vulnerability report needs to. I’ve never seen one indicate a real vulnerability.

Reproduction-less reports about nested dependencies’ security reports spam maintainers like me and actually hamper security by training us to ignore reports. Unless you can demonstrate a real security vulnerability in one of my packages, please don’t send me a report about a nested dependency.

Shown: a maintainer ideating find phrasing that discourages these reports while still encouraging security practices.

original

This Is Probably Not a Real Vulnerability

These excessive reports are produced because traditional scanners such as npm audit and Dependabot don’t have a way to indicate which API(s) in a package are impacted by a reported issue. That means every downstream package that directly or transitively relies on an impacted package -even if they never use the impacted APIs- will get a security report.

👉 See npm audit: Broken by Design for a deep dive into npm audit’s flaws.

Much of the time, the vulnerability is only exploitable if a user runs some carefully crafted malicious code on the server the package is running on. That can be very important to patch for some users of some packages!

But: many packages are only ever used at development time. A linter plugin, for example, will often only be run on safely parsed representations of code written by the project’s developers. That’s not a realistic vector for attacks that require passing a raw untrusted string to a specific API.

Vulnerabilities in my packages -even direct dependencies- might impact users. But something nested deep within a development-only dependency’s dependency? Possible, but much less likely.

💡 Comprehensive tools such as Socket and Snyk provide more options around prioritizing issues and/or ignoring vulnerabilities that don’t impact the APIs you use.

In order to determine whether there’s a real security issue in a package, we’d need to demonstrate an exploit. But…

This Is Not a Real Report

Solely telling me that some automated scan found a potential issue does not amount to a real security report. There are good reasons why security reporting platforms such as HackerOne categorically do not allow reports that don’t include at least a set of steps to achieve an exploit reproduction.

Requiring reproduction steps is important for two goals:

Ensuring reporters have done their due diligence in making sure what they’re reporting is something worth spending time on.
Helping the receiving developer(s) understand exactly what’s being reported.

Again, for emphasis: if you have a real security report then please send it over. But a vague hand-wave at a security advisory on code I do not work on is not going to help me triage your report.

This Is Counterproductive

Developers have finite energy and time budgets - even for important tasks such as security. If any avenue of reporting repeatedly wastes our time, what do you think our reaction is going to be? Just as flakiness in unit tests kills motivation to test, spam false security reports train us to ignore all security reports. That’s bad.

As positive as your intentions may be, it’s counterproductive to take up my time with unnecessary security reports. If you can, I’d recommend instead spending the time to learn how the code in play works - so that you can file an actionable report, and maybe even send a pull request to fix it yourself. ❤️

If you’re a company reading this, please consider sponsoring your open source dependencies. Their development is not free - even if you don’t personally pay for it.

Acknowledgements

Thanks to Lydia Stepanek for reviewing the post and providing helpful feedback & suggestions! 🤝 Thanks also to Ben Durrant for mentioning the npm audit deep dive.