Facebook的软件工程师Dan Abramov发出了呼吁，要求让一款特别烦人的 JavaScript安全工具保持静默——该工具的创建者或多或少也认为确实有改进的空间。
“到今天为止，npm audit堪称整个npm生态系统上的一个污点”，Abramov 在一篇博文中宣称。“修复它的最佳时间就是在将其作为默认工具发布之前。修复它的下一个最佳时间就是现在。”
据Abramov声称，该命令标记出来的安全漏洞中99%是常见使用场景下的误报。而这在广大npm用户当中似乎是一种相当普遍的观点。
十多年前，Isaac Schlueter创建了npm软件包管理器，后来与别人共同创办了一家同名公司，该公司后来被微软的GitHub收购。
2018年4月，npm版本6发布，一并推出了audit命令，原因是npm生态系统中的安全已成为了再也无法忽视的话题。此后，使用npm的JavaScript开发人员只需输入npm audit，就会收到针对其项目的依赖项树的安全分析结果——依赖项树指被导入到项目的各个相互关联的库，那样就没必要从头开始重写通用函数。
问题在于，npm audit矫枉过正。几年前，JavaScript开发人员可能还盼着能发现意外的安全问题，而npm在每次npm install命令之后都会自动执行审计工作，常常生成大量的漏洞报告，这些漏洞可能不容易修复，甚至其实可能不适合实际场景。
在某种程度上，考虑到Node.js生态系统的攻击面，这种情形是不可避免的。由于传递性依赖项，安装一个普通的npm软件包意味着要信任另外大约80个软件包。但是对于Abramov来说，npm audit会在风险实际上不需要担心的情况下生成安全警告，警告过多对任何相关人员都没有帮助。
他写道：“问题的根源在于，npm添加了一种默认行为；在许多情况下，这种行为导致超过99%的误报率，造成了一种令人异常困惑的初次编程体验，导致码农们与安全部门争执，使维护人员永远不想再与Node.js生态系统打交道，并且早晚会导致实际上很严重的漏洞成为漏网之鱼。”
早期的npm团队深表同意
Kat Marchán曾帮助创建了npm audit fix，现在是微软的高级软件工程师，他通过Twitter 回应道：“确实如此”，他还探讨了安全警告和导致当前这种事态的决策方面的几个弊端，其中一些问题与NPM在2018年和2019年管理和人力方面遇到的挑战有关。
Marchán解释：“对于这家公司而言，总的来说这项功能是某种有点儿吓人的营销策略，以推广促销其私有注册中心服务。这倒不是说它不怀好意：对于生态系统的这种安全可见性/改进而言，这么做过去是一种造势手段，现在依然如此。”
Rebecca Turner也参与了创建npm审计功能的工作，现在是微软的首席工程师，她也回应了Abramov的猛烈抨击，承认NPM需要创收影响了设计方面的一些决策。
Turner在Twitter上的一则帖子中写道：“整出戏的开场就是报告所发现漏洞的数量。它没有报告易受攻击模块的数量，而是报告了依赖易受攻击模块的其他模块的数量，数量之大常常超过依赖项树中的模块数量。”
Turner表示，如果她意识到后果，当初会对此提出反对意见，但当时的测试并没有显示过多的漏洞报告。
Turner说：“npm的主线生命周期中没有出现进一步开发这项功能。为了追求盈利，优先事项和资源被挪到了别处。明年会开始讨论如何使审计结果更易于管理……”
“......但是在竭力将这种功能作为高级功能来开发和解雇一半的CLI团队以组织工会（之前团队的另一半成员已辞职）之间，这家公司根本就别无出路。”
这并不像工会炮轰糟糕的npm audit那么简单。这是一大挑战：生成安全警告，以便在适当的场景下在适当的时间提供适当数量的信息。正如Marchan所说：“我本人花了很长的时间来研究讨论audit方面的CLI消息，好让消息尽可能不引人注目。但有时噪音就是噪音，无论你如何努力减少，它都让人分心。”
正在考虑的进一步调整代码也许可以提供一种手动方式来解决审计警告，从而改善这种情形，就像Abramov呼吁有一种方法可以杜绝某些传递性依赖项生成安全警告那样。
但是将安全担忧级别调整到适合所有人、所有情况是吃力不讨好的活儿，但是过分抑制漏洞缓解建议可能只会导致下一起SolarWinds或Kaseya攻击事件。
