存在漏洞的依赖是一个失误。恶意依赖则是一次攻击。二者不是同一类发现，本记录也不会以同样的方式为它们计分。
恶意依赖只问一个问题：这个仓库解析所得的依赖图中，是否含有已被报告为恶意软件的包？
证据来自何处
来源是 OpenSSF 的 malicious-packages 语料库——一份采用开放许可、由社区维护的记录，收录在各公共注册表中被判定为恶意的软件包：仿冒名称抢注、账号被接管、依赖混淆攻击，以及分发预编译恶意二进制文件的包。
OSV.dev 接入该语料库，并以 MAL- 标识符与普通安全公告一并提供。由于本记录已经为依赖安全公告查询 OSV，恶意包是随一次本就要发出的查询一同到达的。这项发现不额外消耗任何请求、任何等待，也不新增对任何第三方的依赖。
为什么与公告分开计分
在方法论 v1.10.0 之前，这类报告被当作普通公告来计数，而这是错的——错在一处值得直白说明的地方。
一份恶意包报告既没有 CVSS 向量，也没有严重程度标注——没有什么可以计分，因为恶意软件没有严重程度，只有一种状态。作为公告计分时，它落入 unknown 严重程度，而该级别的权重等同于一个中等漏洞。一个已被查明会窃取凭据的包，其分量略低于一个平均水平的 CVE。
使漏洞得以计分的三项属性在这里全部缺席：
- 没有修复版本。不存在同一制品的修正发行版可供升级。补救办法是移除，或者弃用这个已被入侵的包名。
- 没有部分暴露。漏洞可能位于无法到达的代码路径中；而安装时执行的载荷，在包被安装时就会运行。
- 没有程度之分。一个包要么被报告为恶意，要么没有。
因此，恶意依赖现在被完全移出公告类发现，并作为一项风险警示处理：它是乘数与上限，而不是扣分。它对安全态势分值以及加权健康指数应用 35% 的乘数，并将二者的上限设为 29——危急等级的顶端。这比 高风险司法辖区的 49 上限严格一个等级，因为这是软件已被确认遭到入侵，而不是暴露于某种风险之下。
同时带有恶意报告与普通 CVE 的包，只会出现在这项发现之下。它的漏洞已无关紧要。
已撤回的制品予以报告，但不计分
注册表移除恶意包，就把问题了结了：不再有可安装之物，解析到它的仓库今天并未分发恶意软件。因此每一项发现都会检查注册表是否仍在提供恰好这一已解析版本。若不再提供，该发现仍留在报告中——项目依赖着一个曾被入侵的名称，这值得被看见——但它不触发风险警示，也不扣任何分。
这项检查刻意询问的是已解析的版本，而不是该包的最新版本。撤下之后，npm 会留下一个标记为 -security 的占位发行版作为该包的最新版本。这保护的是所有解析版本范围的人，而不是任何精确锁定了那个有问题版本的人。若读取最新版本，本项发现首次触发的那个仓库就会被判为干净——而它恰恰把被入侵的包锁定在注册表至今仍在提供的那个精确版本上。
在无法得到答案之处——该检查未覆盖的生态系统，或没有响应的注册表——该发现按包仍然存续来计分。无法访问注册表，并不能证明恶意软件已被撤回。
直接与间接同等计入
本记录的依赖计分大多会区分声明的直接依赖与被传递引入的依赖，因为前者是维护者选择的，后者是继承而来的。
这一区分在此处不适用。包的安装脚本在它于已解析依赖图中所处的任何深度都会执行；深藏四层之下的凭据窃取程序，对机器的入侵与写在清单文件里的那个同样彻底。两者都会被报告、都会被计分，报告并会说明属于哪一种，以便读者看清该包是从何处进入的。
这项发现不主张什么
它不是对维护者的指控。该报告针对的是已发布形态的软件包，无论由谁发布。一个仓库会解析到数以千计它从未审查过的包；继承到一个已被入侵的包，正是这类事情发生的常态，它不说明被扫描仓库的维护者的意图或能力。
它不主张代码曾被执行。这项发现说的是：已解析的依赖图中含有该包。是否有人安装过恰好这一份依赖图，以及若安装了载荷做了什么，都超出公开记录所能观察的范围。
它不是我们的判定。该分类属于 OpenSSF 语料库，由其自身的流程与来源得出，本记录只是报告它，而不是复现它。上游撤回的报告，会在下一次扫描中消失。
触发的频率
很少——这既出于设计，也经过实测。该指标上线前，曾在覆盖 46,889 个已解析依赖的 300 个仓库样本上运行，未发现任何一例。
这正是预期中的结果，并不说明该检查毫无用处。注册表会在发现后数小时至数日内撤下恶意包，因此一份至今仍解析到恶意包的锁文件是不寻常的。这项发现的价值不在于触发得频繁；而在于一旦触发，它就是报告中最重要的那一个事实，并且不会再被平均进某个漏洞分值里。
何时不予评估
与依赖安全公告一样，只要依赖图或 OSV 查询不可用，本指标就会被排除——而不是计为零分。仓库绝不会因为关闭了 GitHub 的依赖图而被扣分；报告会说明这项检查未能运行，而不是暗示结果干净。