我们很高兴地宣布 NPM Package Cooldown Check 的发布，该工具可帮助团队阻止新发布的、可能已被攻陷的依赖项，同时仍允许紧急修复并与 GitHub 工作流程无缝集成。
供应链攻击对开源包构成的威胁日益严峻，已成为平台和安全团队关注的焦点。今天，我们很高兴地宣布 NPM Package Cooldown Check 的发布，这是一款全新的 GitHub 拉取请求（PR）检查工具，旨在自动阻止引入新 npm 包版本的 PR。简而言之，如果某个 PR 试图使用在过去两天内（或在可配置的"冷却"期内）发布的 npm 包版本，此检查将导致 PR 失败。这为您的团队提供了一个短暂的等待窗口，在采用全新依赖项之前进行审视，从而为防范恶意发布提供了至关重要的安全网。这是一种易于访问、对开发者友好的防护措施，可直接集成到您的 GitHub 工作流程中，帮助保护您的应用程序免受供应链攻击，且不会减慢开发速度。
此功能是我们将安全性融入开发生命周期这一更广泛举措的一部分。除了 Cooldown Check 之外，我们还在推出更多 GitHub 检查，以捕获其他供应链威胁——从危险的 GitHub Actions 工作流程漏洞（如"PWN Request"缺陷）到 CI 管道中的脚本注入问题。在本文中，我们将解释 NPM Package Cooldown Check 的工作原理、逐步演示示例、讨论其背后的设计原理，并提供在您的环境中采用的指导。
什么是 NPM Package Cooldown Check？
NPM Package Cooldown Check 是一个轻量级的自动化验证步骤，在每个拉取请求上运行。它的职责很简单：检测 PR 中引入或更新的任何在最近 2 天（48 小时）内发布的 npm 依赖项，如果发现此类依赖项，则使 PR 失败。
"冷却"期是可配置的——默认设置为 2 天，但您的组织可以根据自身的风险承受能力将其调整为更长或更短的窗口期。一旦该包版本的冷却期已过，检查将自动清除，无需手动干预。在实践中，这意味着如果您打开的 PR 将某个库更新为昨天发布的版本，该 PR 将被阻止；但如果您仅仅等待该版本超过 2 天，检查就会通过，您可以正常合并。
图片
NPM Package Cooldown Check 的工作原理
为什么要强制执行冷却期？
您可能会想：为什么要延迟更新？这背后的原理源于近年来软件供应链攻击的惨痛教训。大多数恶意包发布在发布后的前 24 小时内就会被发现，通常是由自动化扫描器、安全研究人员或包维护者发现的。被攻陷的项目通常是那些急于立即采用新版本的。通过在允许新依赖项之前引入短暂的等待期，团队可以在保持依赖项更新的同时大幅降低遭受新攻击的风险。
NX compromise（npm 中的 NX 妥协事件）就是一个鲜明的例子，证明了尽早采用每个新版本的风险。攻击者设法将恶意版本偷偷放入注册表，在短短几个小时内，立即拉取更新的开发者就面临着运行被攻陷代码的风险。幸运的是，问题在最初 24 小时内就被检测到，包也被标记了。同样的模式也在其他包中出现过，比如 es-lint 和 is，这些包的攻陷事件被迅速捕获，但早期升级者已经暴露于风险之中。
这正是 Cooldown Check 要解决的问题。通过自动强制执行新版本被采用前的短暂等待期，它为生态系统争取了反应和标记问题的时间。Cooldown Check 不是仅仅依赖事后发生的漏洞扫描器或 CVE 公告，而是主动暂停未经审查的代码。
对于使用 Dependabot 等自动化依赖项更新工具的团队来说，这种保护措施尤其有价值。启用 Cooldown Check 后，即使 Dependabot PR 也会在指向刚发布的包时被标记，从而降低了意外合并被攻陷版本的风险。48 小时的延迟对于显著减少暴露风险来说是一个小小的代价。
图片
NPM Package Cooldown Check 失败，因为发布的包版本不足 2 天
在上图中，版本 20.12.0 被攻陷，而 20.10.0 则没有。然而，由于 Dependabot 自动更新了依赖项，该仓库最终使用了被攻陷的版本。我们在多次 npm 供应链攻击中观察到这种模式：Dependabot 和 RenovateBot 等自动化依赖升级工具会在发布后迅速创建拉取请求，将版本从安全版本跳到被攻陷版本。因为许多开发者信任这些工具并在没有太多审查的情况下合并 PR，恶意代码通常在攻陷被标记之前就迅速传播开来。
演练：在 PR 中阻止新发布的包
下图展示了 NPM Package Cooldown Check 如何在拉取请求上显示失败。在此示例中，一位开发者试图将依赖项升级到数小时前发布的版本。Cooldown Check 作为 PR 检查的一部分运行，并将新版本标记为太新。在 PR 的状态面板中，您可以看到检查失败，详细信息列出了违规的包名称、版本变更（从先前版本到新版本）、发生变更的文件（如 package.json 或 lockfile），以及新版本的发布时间/日期。检查消息甚至注明了何时会自动通过，表明 2 天冷却期将满足的确切时间。这种即时反馈使团队可以暂缓合并 PR，直到被标记的依赖项超过安全阈值，届时检查将自行变绿。
图片
NPM Package Cooldown Check 失败，因为发布的包版本不足 2 天
总结此检查的开发者体验：
- 开发者（或机器人）打开一个添加或更新一个或多个 npm 包版本的 PR。
- NPM Package Cooldown Check 在 PR 的 CI 工作流程中运行。
- 如果任何引入的包版本是在最近 X 天内发布的（如 2 天），检查失败，PR 被阻止合并。
- PR 显示清晰的错误信息，说明哪个包太新以及需要等待多长时间。
- 冷却期结束后，检查会自动重新运行并通过（假设没有其他问题），解除对 PR 的阻止。团队此时可以放心合并 PR，因为该依赖项已经有了一些时间在社区中"沉淀"。
请按照此交互式演示了解其工作原理：
iframe
在您的管道中采用 Cooldown Check
开始使用 NPM Package Cooldown Check 非常简单。该检查可以作为 GitHub PR 工作流程的一部分启用。平台/安全工程师可以在组织范围内或针对特定仓库将其作为拉取请求上的状态检查来推广。要启用此功能，请参阅我们的文档中的信息。
重要的是，Cooldown Check 无意阻止关键安全补丁。如果上游发布了紧急修复，开发者仍然可以立即合并。在这种情况下，检查最初会失败，因为新包尚未通过冷却期，但 StepSecurity 组织管理员可以覆盖结果并批准 PR。这确保了团队在紧急更新方面保持敏捷性的同时，仍能从针对被攻陷包的保护性默认姿态中受益。
更广泛安全举措的一部分
NPM Package Cooldown Check 是通过 GitHub 原生检查加强软件供应链安全的更宏大努力的一部分。如前所述，我们正在扩展平台，增加额外的自动化 PR 和 CI/CD 检查，以应对困扰现代管道其他类别的漏洞。
NPM Package Compromised Updates Check
此控制确保没有拉取请求引入或更新已知被攻陷的依赖项。StepSecurity 持续监控 npm 生态系统中的新兴威胁，并维护一个被攻陷包的内部数据库，该数据库实时更新。在许多情况下，此数据库在官方 CVE 发布之前就已更新，这意味着开发者可以比传统漏洞扫描器更快地阻止恶意包的使用。如果拉取请求使用了被攻陷的包，检查失败并阻止合并，消除了一种主要攻击向量，并帮助团队以生态系统的速度响应事件。
PWN Request Check
此控制检查 GitHub Actions 工作流程中可能允许 PWN Request 漏洞的模式。它检测可被恶意分叉 PR 利用的不安全配置，例如由 pull_request_target 触发的工作流程，并在这些风险被用来在您的 CI 环境中执行未授权代码之前标记出来。
图片
PWN Request 漏洞检查失败，因为工作流程存在 PWN 请求漏洞
Script Injection Check
此控制扫描 GitHub Actions 工作流程中的脚本注入漏洞。它识别使用过于宽松触发器或未经过滤的外部输入的工作流程，并发出警告或阻止检查，以便在攻击者利用这些问题之前解决这些问题。
图片
脚本注入漏洞检查失败，因为工作流程存在脚本注入漏洞
结论和后续步骤
NPM Package Cooldown Check 的推出标志着向使供应链安全无摩擦且主动迈出的重要一步。我们相信，安全工具在开发者工作流程的幕后运作时效果最佳——在不压垮开发者的情况下提供及时的警报和防护。有了这个新的检查，团队可以继续自信地更新依赖项，知道有一双额外的眼睛（还有一个计时器）在为他们把关。
通过开始免费试用开始使用此功能。