GitHub依赖更新设三天冷却期 遏制供应链投毒攻击

一、政策速览：依赖更新引入“冷却期”默认机制

7月中旬，GitHub官方宣布其自动化依赖管理工具Dependabot正式引入“冷却期”机制，并作为默认配置全面上线：当一个依赖包的新版本在软件仓库发布后，Dependabot至少会等待三天，才会为项目创建版本更新拉取请求。这意味着新版本不会在发布的瞬间被自动引入，而是先给社区留出观察窗口。官方强调，这一默认值仅作用于“版本更新”，真正用于修复已知漏洞的“安全更新”仍会立即推送，关键补丁不会被拖延；用户也可以通过.github目录下dependabot.yml中的cooldown选项自行调整窗口长度，或彻底关闭该机制。新默认值适用于GitHub.com上全部受支持生态的Dependabot版本更新，并将在企业版GHES 3.23中生效。这一改动看似细微，却标志着主流代码托管平台对软件供应链攻击的防御思路发生重要转向：从单纯追求更新速度，转向“用时间换安全”。

二、攻防逻辑：投毒包的“黄金窗口”与时间防御

要理解冷却期的价值，先要看清供应链投毒攻击的运作模式。攻击者往往向npm、PyPI等流行软件仓库推送一个精心构造的恶意版本，它可能伪装成正常功能更新，实则携带窃密或破坏代码。由于下游项目普遍开启自动化依赖更新，恶意版本发布后会在极短时间内被大量项目自动拉取并合入，形成“闪电式扩散”。尽管恶意包通常数天内就会被安全社区发现并从仓库下架，但这段时间已经足够扩大攻击的爆炸半径。GitHub正是瞄准了这一时间差：三天冷却期让依赖更新绕过了恶意版本最常见的存活窗口，等到Dependabot建议升级时，投毒版本多半已被识别和下架。GitHub官方将此称为“金发姑娘”取值，既覆盖了大多数此类攻击的活跃期，又不会不必要地拖延正常依赖升级。当然，时间防御并非万能。GitHub也坦承，冷却期对发布后长期潜伏的后门、维护者账号被攻破、构建系统被入侵等慢速攻击作用有限，它只是多层防线中的一环。

三、行业联动：时间防御已成生态标配

值得注意的是，GitHub并非第一个引入此类机制的平台。过去一年间，类似策略已在多个软件生态落地：微软VS Code将扩展自动更新延迟两小时，Ruby、Bun、npm、pnpm、Yarn等包管理器也相继推出各自的更新延迟策略。与此同时，Python官方仓库PyPI宣布，将阻止维护者在包发布14天后向该发布版本追加新文件，目的正是防止攻击者利用被攻破的发布令牌或CI工作流，向“旧的可信版本”偷偷投毒。7月底，GitHub还密集上线了一批供应链安全能力：npm包发布时恶意软件扫描、恶意包警报覆盖更多生态、Actions疑似恶意工作流挂起人工审批、限制可绕过二因素认证的细粒度令牌等。从“延迟更新窗口”到“锁定历史版本”再到“发布时扫描”，平台方正在用组合拳压缩攻击者的操作空间。对开发团队而言，冷却期之外更基础的实践仍是：用锁文件锁定依赖版本、在CI流水线中禁用安装脚本、为构建令牌设置最小权限、合并依赖更新前进行人工审查。

四、对青海政企的安全启示

对青海的政府机关、医疗机构和企业而言，供应链安全并非遥远的海外话题。等保2.0通用要求已明确将供应链管理纳入安全管理中心范畴，要求对供应商、开源组件、第三方软件开展风险评估。省内不少单位在信息化建设中大量引入开源组件和国产化中间件，一旦上游依赖被投毒，风险会顺着代码链路直达业务系统。建议：一是建立组件台账，梳理系统使用的主要开源组件及版本，对高危组件重点跟踪；二是慎用全自动升级，先在测试环境验证再合入生产；三是在采购与自研项目中明确软件成分清单要求，把供应链安全写进合同条款与验收标准；四是关注国家关于开源软件安全漏洞的通报与预警，及时跟进处置。供应链安全没有一劳永逸的解法，把“时间缓冲、最小权限、持续监控”落实到位，才能在源头压缩攻击面。