GitHub于2026年7月28日宣布Dependabot恶意软件告警开始接入OpenSSF malicious-packages数据覆盖范围扩展到npm、PyPI等更多包生态。本文说明这项变化与npm发布时扫描的区别以及项目收到恶意依赖告警后应检查的5个位置。最近两天GitHub连续更新了两道软件供应链防线npm开始在新包发布时执行恶意软件扫描Dependabot恶意软件告警开始接入OpenSSF的malicious-packages数据。这两个变化很容易被混为一谈但它们解决的问题并不相同。前者发生在软件包进入npm Registry之前扫描结果可能让包正常发布、等待人工审核或被阻止发布后者发生在项目仓库侧用已知恶意软件包数据匹配项目依赖并产生告警。所以Dependabot的这次更新并不意味着每次执行npm install或pip install都会被GitHub自动拦截。它更像是把一张更大的已知恶意包名单接入仓库告警系统。这次到底更新了什么GitHub在2026年7月28日的公告中说明GitHub Advisory Database开始接入OpenSSF malicious-packages项目的恶意软件包报告数据覆盖范围扩展到npm、PyPI等更多生态已经启用Malware alerts的仓库会自动获得扩展后的数据覆盖无需重新配置可以在GitHub Advisory Database中使用type:malware筛选恶意软件告警。OpenSSF的这套数据使用OSV格式收录范围包括恶意包、账户被接管后发布的包、依赖混淆、恶意预编译文件以及安装时执行恶意载荷的包。但需要注意一个文档同步问题截至本文整理时GitHub 7月28日的更新公告已经明确写出npm、PyPI等更多生态而Dependabot malware alerts的独立文档页仍显示“当前适用于npm”。因此不要仅凭公告推断所有PyPI仓库都已经出现相同界面应以具体仓库的Security页面和实际告警结果为准。先确认告警功能有没有真正开启如果仓库没有启用Dependabot alerts或Malware alerts扩充恶意包数据也不会自动变成你能看到的仓库告警。仓库管理员可以进入Repository → Settings → Advanced Security → Dependabot alerts → Malware alertsGitHub的当前说明是已启用Malware alerts的仓库会自动使用新增数据不需要为了这次更新重新创建配置文件。同时还要检查谁能收到通知。默认情况下通常需要同时满足对仓库拥有write、maintain或admin权限正在Watch该仓库通知设置中允许安全告警或全部活动通知。不要等发生事故后才发现告警其实早就产生了只是没有人负责查看。收到恶意依赖告警后先检查这5处1. 锁定包名、版本和告警来源先从告警页面记录包所属生态完整包名受影响版本命中的manifest或lock文件GitHub给出的修复版本或处理建议告警首次出现的时间。不要只根据包名搜索后立即删除。恶意包可能是一个拼写相近的仿冒包也可能是正常包的某个特定版本被维护者账号接管后发布。尤其要注意内部包重名。GitHub官方文档明确提醒如果内部包的生态、名称和版本恰好与公开恶意包一致可能出现误报。即使怀疑误报也应先确认实际下载源和包内容再决定是否关闭告警。2. 找到它是直接依赖还是间接依赖如果它是直接依赖通常能在package.json、requirements.txt或pyproject.toml中直接看到如果是间接依赖只改业务代码里的导入语句可能没有任何效果。Node.js项目可以先运行npmlspackage-namenpmexplainpackage-namePython项目可以保留当前环境快照再检查安装信息python-mpip freezerequirements-current.txt python-mpip showpackage-namepython-mpip inspectpip-inspect.json然后检查项目中的依赖文件package.json package-lock.json yarn.lock pnpm-lock.yaml requirements.txt poetry.lock Pipfile.lock pyproject.toml真正需要回答的问题是是谁把这个包带进来的它最终被锁定成了哪个版本3. 不要直接在原开发机上“试试看”如果被标记的版本已经安装或执行过不建议继续在原开发机、生产服务器或带有真实密钥的CI环境里反复安装测试。更稳妥的处理方式是暂停相关构建、发布和定时任务保留告警、安装日志、lock文件和流水线记录在隔离环境中确认依赖链和替代版本从可信提交和干净环境重新构建完成验证后再恢复部署。删除node_modules或重建Python虚拟环境只能清理当前文件不代表已经消除恶意代码执行后产生的影响。如果恶意包已经运行它可能访问过当前进程能够读取的环境变量、配置文件、缓存和网络资源。此时问题已经不只是“换一个依赖版本”。4. 检查安装脚本、构建脚本和出网行为恶意依赖不一定要等业务代码主动调用。某些包可能借助安装或构建阶段执行脚本。Node.js项目重点检查preinstall install postinstall prepare prepublishOnlyPython项目则要关注构建后端、自定义安装过程、预编译二进制文件以及安装时额外下载的内容。结合CI日志检查是否出现异常域名、IP或下载地址是否新增了没有解释的子进程是否读取了用户目录、SSH目录或云平台配置是否发生未知制品上传是否有环境变量被打印或发送到外部。不能因为项目“还能正常运行”就认为包没有做额外操作。5. 判断哪些凭证需要轮换如果恶意版本曾在开发机、CI Runner或生产环境运行应按它可能接触到的权限范围评估凭证。常见检查项包括GitHub Token、Deploy Key和App私钥npm、PyPI发布令牌云平台访问密钥数据库和对象存储凭证CI/CD Secrets第三方API密钥SSH密钥及其他长期会话凭证。不要无差别重置所有凭证也不要什么都不换。先结合执行环境、进程权限、访问日志和告警时间确定影响范围再按优先级撤销或轮换。一份最小处置清单[ ] 确认Dependabot alerts和Malware alerts已开启 [ ] 保存包名、生态、受影响版本和命中的依赖文件 [ ] 查清它是直接依赖还是由其他包间接引入 [ ] 暂停在带真实凭证的环境中继续安装和执行 [ ] 在隔离环境中替换依赖并重新生成lock文件 [ ] 从干净环境重新构建和测试 [ ] 检查安装脚本、异常出网和日志 [ ] 评估并轮换可能暴露的令牌和密钥 [ ] 记录处理结果不直接以“误报”为由关闭Dependabot不是完整的恶意软件防护GitHub官方也列出了这类告警的边界不能发现所有恶意依赖新报告进入GitHub Advisory Database可能存在时间差只有经过GitHub审核的报告才会触发告警不扫描已经归档的仓库依赖清单和lock文件不准确时检测结果也会受影响。因此Dependabot告警应该是供应链防线中的一层而不是唯一一层。比较稳妥的项目还应当做到依赖升级必须经过代码评审提交并维护lock文件限制安装脚本和构建阶段权限CI使用最小权限和短期凭证依赖来源、维护者和版本变化可追踪生产构建尽量使用可复现、干净的环境出现异常后保留日志和事件时间线。还要分清npm的新发布扫描同一天npm还宣布了发布时恶意软件扫描。新发布的npm包在可供安装前会先接受自动扫描可能正常发布、等待人工审核或被阻止。GitHub表示通常会产生约5分钟的可用延迟高峰期或大型包可能达到15分钟以上但这些时间不是服务承诺。这会影响“发布完成后立即安装”的自动化流程。维护npm包的人应让流水线能够容忍短暂延迟不要因为刚执行完npm publish就假设该版本已经可以下载。它与Dependabot的关系可以概括为机制发生位置主要作用npm发布时扫描包进入npm Registry前检查新发布包可能审核或阻止发布Dependabot恶意软件告警项目仓库依赖侧根据已知恶意包数据发现受影响依赖一个负责入口一个负责项目侧发现不能互相替代。结论Dependabot接入OpenSSF malicious-packages后恶意依赖告警的数据范围扩大了这是有价值的供应链安全更新。但最需要纠正的认知是告警扩大不等于安装自动被拦截也不等于项目没有告警就一定安全。真正收到告警时不要只把版本号升级一下就结束。先查依赖来源再判断恶意版本是否执行过、接触过哪些凭证最后从干净环境重新构建。依赖问题的修复目标不只是让红色告警消失而是确认这段依赖关系没有继续留下不可解释的风险。官方资料GitHubDependabot恶意软件包告警扩展GitHub DocsDependabot malware alertsGitHub Docs配置Dependabot alertsOpenSSF malicious-packagesGitHubnpm发布时恶意软件扫描