GitHub 将 Dependabot 针对恶意软件包的警报范围从 npm 扩展至八个生态系统，此前 GitHub Advisory Database 已与专门收集恶意软件包数据的 OpenSSF 仓库建立连接。新增覆盖范围包括 npm、PyPI、Maven、RubyGems、NuGet、Go、crates.io 和 PHP Composer，从而能够在使用 JavaScript 以外语言和工具的项目中检测恶意依赖项。
今年早些时候，Dependabot 已开始检测 npm 依赖项中的恶意软件。此次扩展依靠以 OSV 格式导入 OpenSSF 记录，而不是为每个生态系统分别构建检测系统。据该文章称，OpenSSF 仓库自 2023 年推出以来已收录超过 15,000 份报告，并通过社区举报和自动检测来源持续增长，其中包括名称相似的软件包、依赖混淆软件包、账户接管以及恶意预构建二进制文件。
统一的恶意软件包数据导入器
GitHub 的供应链安全工程团队开发了一个统一导入器，其模式与处理公共安全公告仓库的导入器相同。该导入器读取自上次运行以来发生变化的文件，然后根据 OSV 模式验证必填字段、类型和格式，之后才将记录写入数据库。验证失败的记录会被拒绝并记录下来以供审查，而不会被自动修改后放行。
记录通过验证后，会被转换为包含来源、标识符以及可用时的 CVE 标识符的馈送条目，同时完整保存原始记录作为参考副本。导入器还会处理不同来源之间的数据差异，例如 OpenSSF 使用 PyPI 这一名称，而 GitHub 数据库使用 pip；将受影响版本表示为单独的值而不是范围；某些报告缺少可用版本；以及撤回后来被证明不正确的报告。
防止重复并保护发布流程
另一个问题在于，GitHub 本身也会向 OpenSSF 仓库贡献数据，而 GitHub 针对 npm 恶意软件的警报也会流入该仓库。为防止重新导入相同数据，导入器依靠 OSV 中的记录来源数据，并排除任何带有 ghsa-malware 标签的条目，因为这些条目最初来自 GitHub。文章指出，每月进入该仓库的新 npm 报告中有一半以上源自 GitHub 的警报，因此会被排除，以避免形成重新导入循环。
恶意软件警报会自动发布，不会在发布前对每份报告逐一进行人工阅读，因为当软件包正在窃取凭据时，将警报延迟数天可能会给攻击者额外的时间。这不同于漏洞警报，后者通常需要人工验证软件包匹配情况、版本范围和问题严重程度。
处理错误数据的三层机制
- 批次限制：每次运行都会设定一个可配置的上限，规定能够创建的警报数量。如果数据超过该上限，运行将完全停止，不会发布任何内容，同时会发送警报的精确数量。
- 来源追踪：每条警报都与 malicious-packages 仓库中的特定提交相关联，因此可以在发生事故时确定报告来源。
- 回滚：如果有污染数据泄漏，可以将每个批次作为一个整体定义并回滚，而不必手动从数据库中删除警报。
面向用户的启用方式
Dependabot 中的恶意依赖项警报现已可选启用，可从仓库、组织或企业环境的安全设置中启用。启用后，Dependabot 会将依赖项与 GitHub Advisory Database 中的恶意软件警报进行匹配，包括对现有警报执行后续匹配。