> the tooling isn't yet able to differentiate between dependencies which are packaged and deployed with your application vs dependencies which are only used in

> the tooling isn't yet able to differentiate between dependencies which are packaged and deployed with your application vs dependencies which are only used in the build process You can run npm audit --production to audit only the "dependencies" that are what deployed code is using, but not "devDependencies" which are what build and test infrastructure is using. > That's not a vulnerability, that's a broken build. True, but at the same time you shouldn't discount the potential issues in the build toolchain as totally harmless. A classical example is a malicious transitive dependency that steals your signing keys. Or triggers long builds, slowly (or rapidly) burning your money that you pay for CI. The thing is, with every potential vulnerability you should assess whether it actually applies to you. There are countless reasons for which a vulnerability cannot be exploited in your particular situation: you don't even use a feature, you use it with proper safeguards, you don't deploy that code to anywhere that matters, you run it in a sandbox, etc. But doing so is not that easy when you have hundreds of transitive dependencies and npm audit cries wolf daily. I have this little library with exactly one direct dependency and what do I see? found 7 vulnerabilities (4 moderate, 3 critical) in 124 scanned packages This is doable. Now multiply it by 200 and you can't be bothered to review it all and decide whether things apply to you or not. Extreme positions are to either ignore the advisories entirely (“it’s not an issue until I have a real user with a real complaint”), or treat all of them as immediate priority (“npm audit says we have 7 critical vulnerabilities, those must be real and actual, drop whatever you're doing and fix that NAO”). A middle ground is some arbitrary policy, like don't sweat it until we have more than N potential vulnerabilities, or someone happened to read their descriptions and thinks they are particularly nasty. The bad thing here is that the npm audit scale promotes this sort of middle ground position taking without involving actual security people.