<story><title>Npm Audit: broken by design?</title><url>https://overreacted.io/npm-audit-broken-by-design/</url></story><parent_chain><item><author>JonathonW</author><text>A regex &amp;quot;denial of service&amp;quot; &amp;quot;vulnerability&amp;quot; &lt;i&gt;could&lt;/i&gt; be important, if it shows up in code that processes untrusted input from end users.&lt;p&gt;But NPM Audit has no idea of context--  a &amp;quot;critical&amp;quot; bug in `browserlist`, which, in this context, is never used outside the development process and never takes input outside of what&amp;#x27;s in my package.json, gets the same prominence (or more so, since it&amp;#x27;s early in alphabetical order) as a &amp;quot;critical&amp;quot; bug in Express, potentially allowing my server to be compromised.&lt;p&gt;I&amp;#x27;m not really sure what the solution is here; NPM&amp;#x27;s just a package manager and doesn&amp;#x27;t know &lt;i&gt;how&lt;/i&gt; you&amp;#x27;re using a given package.  A simple heuristic distinguishing development dependencies and runtime dependencies in NPM Audit might be a start, but that doesn&amp;#x27;t help with situations like create-react-app&amp;#x27;s react-scripts where &lt;i&gt;everything&lt;/i&gt;, runtime or dev dependency, is a transitive dependency of one package declared as a runtime dependency.</text></item><item><author>esens</author><text>I found that much of the underlying cause is those mass reporting regex denial of services as being high severity bugs.&lt;p&gt;So many people are reporting these in tons of different projects: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;search?q=regex+denial+of+service&amp;amp;type=issues&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;search?q=regex+denial+of+service&amp;amp;type=iss...&lt;/a&gt;&lt;p&gt;Anyhow it is just annoying and they broke NPM Audit based on these reports.&lt;p&gt;It is good to fix all possible bugs, but many of these are not anywhere close to the level of bad that the reports are making them to be.&lt;p&gt;But maybe this is needed to just get rid of these issues in genera?  So a wave of regex vulnerability reports and then we build this type of checking into prettier or similar and we do not have these in the future?&lt;p&gt;EDIT: It appears there as a project that found 100s of CVE reported Regex vulnerabilities in npm projects -- this is maybe one of the sources of mass reports.  See the bottom of this resume: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;yetingli.github.io&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;yetingli.github.io&lt;/a&gt;</text></item></parent_chain><comment><author>IggleSniggle</author><text>Agreed!&lt;p&gt;A “Critical” bug in a dev context should mean something very different from a “Critical” bug in a prod context. A “Critical” devDependency bug should be either a direct threat to the developer’s context, either by infecting the dev machine or by injecting a supply-chain problem, worming it’s way into downstream contexts.&lt;p&gt;npm audit is just not granular OR careful enough to address these issues appropriately.</text></comment>
<story><title>Npm Audit: broken by design?</title><url>https://overreacted.io/npm-audit-broken-by-design/</url></story><parent_chain><item><author>JonathonW</author><text>A regex &amp;quot;denial of service&amp;quot; &amp;quot;vulnerability&amp;quot; &lt;i&gt;could&lt;/i&gt; be important, if it shows up in code that processes untrusted input from end users.&lt;p&gt;But NPM Audit has no idea of context--  a &amp;quot;critical&amp;quot; bug in `browserlist`, which, in this context, is never used outside the development process and never takes input outside of what&amp;#x27;s in my package.json, gets the same prominence (or more so, since it&amp;#x27;s early in alphabetical order) as a &amp;quot;critical&amp;quot; bug in Express, potentially allowing my server to be compromised.&lt;p&gt;I&amp;#x27;m not really sure what the solution is here; NPM&amp;#x27;s just a package manager and doesn&amp;#x27;t know &lt;i&gt;how&lt;/i&gt; you&amp;#x27;re using a given package.  A simple heuristic distinguishing development dependencies and runtime dependencies in NPM Audit might be a start, but that doesn&amp;#x27;t help with situations like create-react-app&amp;#x27;s react-scripts where &lt;i&gt;everything&lt;/i&gt;, runtime or dev dependency, is a transitive dependency of one package declared as a runtime dependency.</text></item><item><author>esens</author><text>I found that much of the underlying cause is those mass reporting regex denial of services as being high severity bugs.&lt;p&gt;So many people are reporting these in tons of different projects: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;search?q=regex+denial+of+service&amp;amp;type=issues&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;search?q=regex+denial+of+service&amp;amp;type=iss...&lt;/a&gt;&lt;p&gt;Anyhow it is just annoying and they broke NPM Audit based on these reports.&lt;p&gt;It is good to fix all possible bugs, but many of these are not anywhere close to the level of bad that the reports are making them to be.&lt;p&gt;But maybe this is needed to just get rid of these issues in genera?  So a wave of regex vulnerability reports and then we build this type of checking into prettier or similar and we do not have these in the future?&lt;p&gt;EDIT: It appears there as a project that found 100s of CVE reported Regex vulnerabilities in npm projects -- this is maybe one of the sources of mass reports.  See the bottom of this resume: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;yetingli.github.io&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;yetingli.github.io&lt;/a&gt;</text></item></parent_chain><comment><author>Angius</author><text>IMHO one solution would be to categorize vulnerabilities separately for prod dependencies and dev dependencies, and bubble that categorization up.&lt;p&gt;For example, a RegEx DDoS vulnerability in Express would show up as high severity, while the same would not show in the bundler you use, or any package that your bundler has in its dependency tree.</text></comment>