近日，GitHub 对 Dependabot 的依赖更新机制进行调整，引入默认三天的“冷却期”。今后，当软件包发布新版本后，Dependabot 不会立即创建版本升级拉取请求，而是等待至少三天后再执行更新，以降低恶意软件包在短时间内快速进入下游项目的风险。
需要注意的是，这项机制主要针对常规版本更新，并不会影响安全更新。一旦某个依赖被确认存在安全漏洞，Dependabot 仍可及时发出安全警报，并推动项目升级至已经完成漏洞修复的版本。
近年来，开源软件供应链逐渐成为攻击者重点关注的目标。
一种较为典型的攻击方式是：攻击者获取软件包维护权限或发布凭证后，将植入恶意代码的新版本上传至公共软件仓库。由于大量项目使用自动化依赖更新工具，新版本发布后可能迅速被下游项目获取、测试甚至合并。
即使恶意版本很快被发现并从软件仓库撤下，在这段短暂的时间窗口内，仍可能已经影响大量项目。
GitHub 此次增加三天等待时间，相当于在“软件包发布”和“下游自动升级”之间增加一道缓冲区。如果新版本存在明显异常，社区、安全研究人员以及软件仓库维护方将获得更多发现和处置问题的时间，从而减少投毒软件包快速扩散的可能性。
GitHub 将三天作为默认等待时间，主要是在安全性与更新效率之间寻找平衡。
如果等待时间过短，很难有效避开恶意软件包刚刚发布后的高风险阶段；如果时间设置过长，又可能影响正常项目获取新功能和问题修复的效率。
因此，三天并不是绝对的安全期限，而是一项风险缓冲机制。开发者仍可以通过 dependabot.yml 调整相关配置，根据项目自身安全要求设置不同的冷却时间。
GitHub 同时强调，Dependabot 的冷却机制只是软件供应链多层防御体系中的一个环节，不能单独依靠这一措施保障依赖安全。
例如，如果恶意代码长期隐藏在正常版本中，软件包维护者主动植入后门，或者攻击者已经控制构建系统，那么单纯等待三天并不能有效解决问题。
对于企业和开发团队而言，还需要结合依赖锁定、代码审查、CI/CD 权限控制、构建环境隔离等措施共同降低供应链风险。
其中包括使用锁文件固定依赖版本、限制构建流水线令牌权限、谨慎执行第三方软件包安装脚本，并在依赖升级合并前进行必要的代码与安全检查。
实际上，为软件包更新增加等待时间正在逐渐成为开源生态的一种安全防护思路。
包括 VS Code、Ruby、Bun、npm、pnpm、Yarn 等项目或软件生态，都已经陆续探索类似的延迟更新或安全控制措施。
与此同时，Python Package Index（PyPI）也在加强软件包发布后的安全限制，例如针对已经发布的软件版本设置一定时间窗口，限制维护者继续添加新的文件，以降低攻击者盗取发布凭证后向可信版本追加恶意内容的风险。
Dependabot 增加三天冷却期，看起来只是一次较小的功能调整，但背后反映的是软件供应链安全防护思路的变化。
过去更多关注“软件包有没有漏洞”，现在则进一步关注“一个存在问题的软件包发布之后，如何避免它在最短时间内扩散到大量项目”。
自动化依赖更新提高了开发效率，但同样意味着一个恶意版本也可能借助自动化机制快速传播。
因此，在自动更新流程中加入适当的观察期，本质上是在效率和安全之间增加一道缓冲层。
对于依赖大量开源组件的企业来说，这类机制也再次提醒开发团队：依赖版本“越新越好”并不一定成立。相比第一时间自动升级，对新版本进行短期观察、结合漏洞情报和代码审查后再完成更新，可能是一种更加稳妥的软件供应链管理方式。
网站资讯
渠道合作
解决方案
更多服务
