[dale_glass]

It's a tricky problem to solve.

Ideally you'd want to show only relevant alerts, but... how? You'd need to know which kind of errors are relevant for a particular project, but that'd require solving the halting problem. This is made much worse by that it's JS.

Some libraries have an enormous complexity and attack surface. Take a database interface -- there probably is a vulnerability in some obscure corner the typical person may not even know exists.

I think though at the very least some improvement could be made by better priorization and categorization. DoS by exploiting a regex parser isn't that big of a deal if your project is just getting started, but an exploit allowing arbitrary code execution would still be.

[minxomat]

You don't have to go all out doing exhaustive dynamic analysis. Data flow analysis gets rid of 99% of the most popular bugs (injection, validation, defaults, etc.). GitHub CodeQL can do this, and produces much better results than any static analysis tool I've ever used. Feeding this data back into npm (owned by GH) is just the next step.

[scottfr]

You just need a way for a package maintainer to flag a vulnerability in a dependency as a non-issue that does not affect that package's use of the dependency.

In Dan's twitter thread, he calls this out as a viable solution.