文章总结： GitHub对Dependabot非安全版本更新默认设置三天冷静期，防止恶意版本快速扩散；PyPI限制发布超14天的版本不能再添加新文件。企业应区分安全修复、普通更新和高影响升级，分别采用不同策略，并配合锁文件、最小权限和人工审批。自动化应匹配证据成熟度，不能只追求最快更新。 综合评分： 90 文章分类： 供应链安全,安全建设,安全工具,解决方案,漏洞预警

依赖更新越快越安全吗？GitHub 的三天等待给自动化踩了刹车

原创

tcode tcode

字节脉搏实验室

2026年7月28日 10:17 北京

在小说阅读器读本章

去阅读

    GitHub 7 月 23 日宣布，Dependabot 对非安全性的版本更新默认至少等待三天再创建拉取请求。这个时间可以在 dependabot.yml 中调整。安全更新不受默认等待影响：发现已知漏洞并存在修复版本时，告警和修复拉取请求仍会立即推进。

    7 月 27 日，The Hacker News 与 SecurityWeek 对这一变化作了进一步报道。GitHub 的目标不是否定快速更新，而是针对一种特定攻击：维护者账号或发布流程被接管后，恶意新版本短暂出现在公共仓库，自动化工具在社区发现并下架它之前，已经把版本送进大量下游项目。

    三天等待解决的，是“刚发布就被吞下去”

    开源仓库的新版本通常拥有天然的时间优势。发布几分钟内，机器人会检查、提单，某些团队甚至自动合并和部署。恶意版本只需要存活很短时间，也可能进入锁文件、缓存、构建镜像和制品仓库。即使上游随后删除，已经落入内部流水线的副本不会自动消失。

    冷静期改变的是顺序：先让维护者、研究人员和扫描系统观察一段时间，再让普通版本更新进入项目。GitHub 将三天称为在风险与新鲜度之间的平衡点，并允许项目按自己的发布节奏调整。

    但三天不是“安全观察期满”的证明。GitHub 明确指出，它主要针对发布后很快被发现并撤回的恶意版本，对长期潜伏的后门、维护者主动破坏、构建系统被入侵等场景作用有限。如果团队把“已等待三天”改写成“已验证安全”，只是把自动化误判推迟了三天。

    PyPI 的 14 天规则处理的是另一种可变性

    PyPI 7 月 22 日宣布：一个版本发布超过 14 天后，不再允许向该版本追加新文件。其目标是防止攻击者获得发布令牌或工作流权限后，向一个长期稳定、已经建立信任的旧版本补上传恶意构建文件。

    这与 Dependabot 冷静期不是同一控制。GitHub 降低新版本过快扩散的风险；PyPI 限制旧版本在长时间后继续变化。前者控制“何时采用”，后者收紧“发布对象还能否改变”。两者都在减少软件供应链中容易被自动化忽略的时间差。

    PyPI 同时提醒，用户暂时不应把这项行为当作稳定可查询的安全语义，因为相关 API 与“关闭发布”的正式定义仍待后续标准化。它是一项平台防护，不是项目可以删除锁文件、哈希验证和来源审计的理由。

    企业不应把所有依赖设成同一个等待时间

    真正可执行的策略，需要先把更新分成三类。

    第一类是安全修复。当漏洞已确认、修复版本可用且项目真实受影响时，重点是缩短暴露窗口。Dependabot 的默认三天等待不会拦截安全更新，企业也不应为了统一策略人为增加等待。高风险修复要结合可达性、运行环境和回归结果快速推进。

    第二类是普通小版本和补丁版本。适合使用三天或企业自定义冷静期，让上游撤回、社区告警和恶意包扫描有机会出现。等待结束后仍应查看发布说明、维护者变化、安装脚本和依赖树差异。

    第三类是高影响升级。涉及身份、构建插件、序列化、原生扩展或生产基础设施的依赖，即使版本看起来只是小改动，也应进入人工复核。这里的判断依据是依赖拥有的权限和执行位置，而不是语义化版本号的大小。

    自动生成拉取请求之后，团队还要控制合并节奏。低风险开发依赖可以在测试通过后自动合并；会在安装阶段运行代码、进入生产镜像或获得发布令牌的依赖，应要求代码所有者复核。机器人负责发现更新，不应同时拥有绕过保护分支、批准变更和触发生产发布的完整链路。

    把冷静期接进流水线，而不是只改一个配置

    1. 为普通版本更新设置冷静期，并区分生产、开发工具和仅测试依赖，不让所有项目共享一个机械值。

    2. 保留锁文件和完整性校验，依赖解析必须可重复；制品仓库记录首次引入时间和来源，不因上游删除而丢失调查证据。

    3. 在 CI 中默认关闭不必要的安装脚本，构建令牌只允许读取必要仓库，发布令牌与普通构建任务隔离。

    4. 自动合并前检查维护者变化、异常新增文件、安装阶段行为和间接依赖扩大。高权限依赖至少保留一名人工审批者。

    5. 安全修复单独走快速通道，验证项目确实受影响后尽快合并，不让普通版本的冷静期拖慢风险修复。

    对平台团队而言，最关键的指标不是“依赖机器人每天开了多少单”，而是恶意或错误版本从发布到进入生产之间有多少独立检查。只有时间，没有检查，冷静期只是排队；只有检查，没有时间，社区证据可能还没来得及出现。

    信息边界

    已确认：GitHub 对 Dependabot 普通版本更新启用默认三天冷静期，安全更新仍即时处理，等待时间可配置；PyPI 已开始拒绝向发布超过 14 天的版本添加新文件。

    本文判断：成熟的供应链自动化不应只追求“最快拿到最新版”，而应让采用速度与证据成熟度匹配。

    结语

    过去的软件更新逻辑是“越新越好、越快越好”。供应链攻击让这个口号缺了一半：安全修复要快，普通新版本则要给验证留出时间。

    GitHub 的三天和 PyPI 的 14 天不是万能数字，而是两个方向明确的设计信号。让新版本先被看见，让旧版本不再悄悄变化，再配合锁文件、最小权限和人工审批，自动化才能从扩散器变成防线。

参考来源

• GitHub Blog：The case for a cooldown（2026-07-23 16:00 UTC；北京时间 2026-07-24 00:00）

• PyPI Blog：Releases now reject new files after 14 days（2026-07-22，页面未显示具体时区）

• The Hacker News：GitHub Adds 3-Day Dependabot Cooldown（2026-07-27 13:31:23 +05:30；北京时间 16:01:23）

• SecurityWeek：New GitHub, PyPI Policies Boost Supply Chain Security（2026-07-27 14:26 UTC；北京时间 22:26）

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：字节脉搏实验室 tcode tcode《依赖更新越快越安全吗？GitHub 的三天等待给自动化踩了刹车》