文章建议采用"依赖冷却期"来防范开源供应链攻击，认为这是一种简单有效的方法。作者呼吁更多项目通过工具实施该措施，并建议包管理生态系统原生支持此功能，以应对当前被过度炒作的供应链安全问题。

依赖冷却期：抵御开源供应链攻击的简单有效方案

核心观点：依赖冷却期（dependency cooldowns）是一种免费、易实施且高效的方法，能有效防范大多数开源供应链攻击。建议开发者通过Dependabot或Renovate等工具为项目依赖设置冷却期，同时呼吁包管理生态系统在工具层面原生支持该功能。

供应链攻击的典型模式

当前开源供应链攻击通常遵循以下流程： 1. 攻击者通过窃取凭证或利用CI/CD漏洞（如GitHub Actions的"pwn requests"）入侵流行开源项目 2. 植入恶意代码并发布到PyPI/npm等平台（攻击进入公开阶段） 3. 用户通过自动更新或未锁定的依赖获取恶意版本 4. 安全厂商扫描发现异常并上报 5. 官方仓库下架问题版本（通常在攻击公开后数小时至数天内完成） 6. 用户开始修复

关键发现：攻击准备阶段（1-2步）可能持续数周，但实际攻击窗口（2-5步）通常不超过一周。通过分析近18个月的10起典型攻击案例，8起的攻击窗口短于7天，仅xz-utils例外（5周）。

冷却期机制详解

实施方式： - 定义依赖包发布后的观察期（如7天），期间禁止自动更新 - 主流工具支持： yaml # Dependabot示例 version: 2 updates: - package-ecosystem: "github-actions" cooldown: default-days: 7 - Renovate的minimumReleaseAge参数 - pnpm等包管理器的原生支持

核心优势： 1. 实证有效：可防范80-90%的短期攻击 2. 零成本实施：现有工具链直接支持 3. 正向激励：促使安全厂商提高检测质量而非制造恐慌

实施建议与局限

最佳实践： - 基础防护：7天冷却期可拦截大多数攻击 - 强化防护：14天冷却期可防御除xz-utils外的所有案例

注意事项： - 非万能方案：无法防范长期潜伏攻击（如xz-utils） - 本质仍是信任问题：需结合其他安全措施 - 期待生态支持：建议包管理器原生集成该功能

通过这种简单措施，开发者能以极小成本显著降低供应链攻击风险，在复杂的安全环境中建立第一道有效防线。

（注：原文中的技术细节、案例数据和工具说明均予保留，删减了部分重复说明和注释链接）

以下是评论内容的总结：

支持依赖冷却期（Cooldown）的观点

1. 安全优势：延迟更新可以避免新引入的安全漏洞，让社区有时间发现潜在问题。

   • "A lot of security problems can be solved by moving slower."（33a）
   • "The Debian stable model... looks more and more sane as years pass."（gr4vityWall）

2. 自动化与集中化：建议通过CI自动化检查和集中化服务（如LLM分析安全报告）来提高效率。

   • "You could do a lot of this with CI... automatically merge this update."（elevation）
   • "centralize this capability as a service... served only the most vetted packages."（elevation）

反对依赖冷却期的观点

1. 漏洞暴露风险：冷却期可能让已知漏洞在系统中停留更长时间。

   • "Doesn't this mean you're leaving yourself open to known vulnerabilities...?"（jayd16）
   • "Delaying real bugfixes to achieve some nebulous... security benefit is just bad engineering."（jcalvinowens）

2. 集体行动问题：如果所有人都延迟更新，漏洞的发现率会降低。

   • "Except if everyone does it chance of malicious things being spotted... drops."（Havoc）
   • "If everybody does it, it won't work so well."（perlgeek）

替代方案与补充建议

1. 依赖最小化与LTS：减少依赖数量，优先使用长期支持（LTS）版本。

   • "limit the number and complexity of dependencies... small and clean."（cosmic_cheese）
   • "Libraries... should offer LTS releases... only security patches."（cosmic_cheese）

2. 手动审核与源控制：建议结合人工审核或直接管理依赖源码（vendoring）。

   • "upgrade once there are N independent positive reviews..."（nicoburns）
   • "practice... source control... can be 100% mitigated by cutting out the vulnerable supply chain."（cxr）

3. 动态更新策略：根据更新类型（如SemVer版本）调整冷却期长度。

   • "a patch version increment could have a shorter cooldown."（compumike）
   • "waiting N days, or until 2.4.1 comes out and fixes the new bugs."（compumike）

其他中立观点

• 实际风险有限：多数漏洞需要特定条件才能利用，监控比即时更新更重要。
  • "Most vulnerabilities... are only exploitable under special circumstances... monitor your dependencies."（layer8）
• 管理压力：开发者可能因业务需求被迫忽略冷却期。
  • "mid-level managers... will lean on the devs to cut corners."（OhMeadhbh）

总结：评论围绕依赖冷却期的安全性与风险展开，支持者强调其稳定性优势，反对者指出漏洞暴露和集体行动问题，同时提出了依赖管理、审核和自动化等替代方案。