本文来自微信公众号“嘶吼专业版”，作者/胡金鱼。
流行的开源项目“ip”的GitHub存储库最近被其开发人员存档或设为“只读”，由于Fedor Indutny的项目收到了CVE报告，因此网上有人开始向他报告这个漏洞。
不幸的是，Indutny的案例并非孤例。近年来，开源开发者收到的有争议的CVE报告数量不断增加，有些甚至是未经确认的伪造CVE报告。
这可能会导致这些项目的用户产生不必要的恐慌，并且安全扫描程序会生成警报，而所有这些都会成为开发人员的头痛之源。
“node-ip”GitHub存储库已存档
本月初，“node-ip”项目的作者Fedor Indutny将该项目的GitHub存储库存档，实际上使其成为只读的，并限制了人们打开新问题（讨论）、拉取请求或向项目提交评论的能力。
node-ip GitHub repo已存档并设为“只读”
“node-ip”项目作为“ip”包存在于npmjs.com注册表中，每周下载量达1700万次，是JavaScript开发人员使用的最受欢迎的IP地址解析实用程序之一。
6月底，Indutny在社交媒体上表达了存档“node-ip”背后的理由与CVE-2023-42282有关，这是该项目今年早些时候披露的一个漏洞。
使用其他开放项目（例如应用程序中的npm包和依赖项）的Node.js开发人员可以运行“npm audit”命令来检查其应用程序所使用的这些项目中是否有针对它们的漏洞报告。
Bothered dev的开发人员在社交媒体上表达了他的担忧
该CVE与实用程序无法正确识别以非标准格式（例如十六进制）提供给它的私有IP地址有关。这会导致“node-ip”实用程序将私有IP地址（十六进制格式）如“0x7F.1...”（代表127.1...）视为公共IP地址。
如果应用程序仅依赖node-ip来检查提供的IP地址是否公开，则非标准输入可能会导致受影响的实用程序版本返回不一致的结果。
“可疑”的安全影响
公开消息称，CVE-2023-42282最初的评分为9.8，即“严重”。尽管Indutny在其项目的后续版本中修复了该问题，但他否认该漏洞构成了实际威胁，以及严重程度较高。
该开发人员早些时候写道：“我认为该漏洞的安全影响相当可疑”，并要求GitHub撤销CVE。
正如GitHub安全团队成员所解释的那样，对CVE提出异议不是一件容易的事，它要求项目维护者追踪最初发布CVE的CVE编号机构(CNA)。
CNA通常包括NIST的NVD和MITRE。过去几年，科技公司和安全供应商也加入了这一名单，并能够随意发布CVE。这些CVE以及漏洞描述和报告的严重性评级随后被其他安全数据库（如GitHub公告）联合发布。
在Indutny在社交媒体上发布帖子后，GitHub降低了其数据库中CVE的严重性，并建议开发人员开启私人漏洞报告，以便更好地管理传入的报告并减少噪音。
在撰写本文时，该漏洞在NVD上的严重程度仍然为“严重”。
日益严重的滋扰
CVE系统最初旨在帮助安全研究人员以合乎道德的方式报告项目中的漏洞，并在负责任的披露后对其进行分类，但最近吸引了一部分社区成员提交未经核实的报告。
虽然许多CVE都是由负责任的研究人员善意提交的，并且代表了可信的安全漏洞，但最近出现了一种新模式，新手安全爱好者和漏洞赏金猎人表面上“收集”CVE来丰富他们的简历，而不是报告构成现实世界、实际利用影响的安全漏洞。
因此，开发人员和项目维护人员进行了反击。
2023年9月，著名软件项目“curl”的创建者Daniel Stenberg斥责了“虚假curl问题CVE-2020-19909”，这是针对该项目报告的一个拒绝服务漏洞。
根据NVD的历史数据，这个现在备受争议的CVE的严重程度最初被评为9.8级或严重程度，但在随后的讨论中，该漏洞对安全造成的实际影响引发质疑，随后其评级被降至“低”3.3级。
“这不是一个独特的例子，也不是第一次发生。这种情况已经持续多年了，”斯滕伯格在批评CVE条目时写道。
另一个npm项目micromatch每周下载量达6400万次，但报告称存在“高”严重程度的ReDoS漏洞，社区成员正在追查其创建者，询问这些问题。
针对未经验证的漏洞报告发布CVE的行为类似于针对项目、其创建者及其更广泛的消费者群体发起拒绝服务(DoS)。
开发人员安全解决方案（例如npm audit）旨在防止易受攻击的组件进入用户的应用程序，如果检测到任何已知漏洞，可能会触发警报，并且根据用户的设置，可能会破坏用户构建。
“几个月前有人报告了针对该项目的一个关键CVE，并认为其破坏了全球的构建，”一位评论员在2023年针对虚假的curl CVE做出反应时写道。
正如其他开发人员所说，这个问题并不是项目的安全问题，而是Java递归数据结构的固有性质。
平衡点在哪里
此类事件频发引发了人们的疑问：如何才能取得平衡？不断报告理论上的漏洞可能会让开源开发者（其中许多是志愿者）因筛选而精疲力竭。
另一方面，如果安全从业人员（包括新手）对他们认为的安全漏洞置之不理，不免给项目维护人员带来不便，这是否合乎道德？
第三个问题出现在没有活跃维护者的项目上。多年无人触及的废弃软件项目包含漏洞，即使被披露，也永远不会被修复，而且没有办法联系其原始维护者。
在这种情况下，包括CNA和漏洞赏金平台在内的中介机构就陷入了困境。
在收到研究人员的漏洞报告后，这些组织可能并不总是能够独立地充分审查每一份此类报告。在没有得到（现已缺席的）项目维护者的意见的情况下，他们可能会被迫在“负责任的披露”窗口期过后分配和发布CVE。
目前，这些问题均没有答案。
在安全研究人员、开发人员和供应商社区齐心协力找到有效的解决方案之前，开发人员必然会对虚假报告感到沮丧，而CVE系统也将充斥着夸大的“漏洞”，这些漏洞在纸面上看起来可信，但实际上毫无意义。
