推出 Secure Registry：为 npm 供应链提供安装时防御

发布 StepSecurity Secure Registry：npm 供应链的安装时防御。拦截恶意包、强制包冷却期，并保护 CI/CD 管道、开发人员机器和制品仓库免受现代软件供应链攻击。

[图片]

上周，TeamPCP 威胁组织发布了多个 @tanstack npm 包 的恶意版本。这些包每周合计被下载数百万次，携带着一个自我传播的蠕虫，会窃取 CI/CD 凭证，并用它们来发布受感染维护者控制的所有包的恶意版本。这个名为 Mini Shai-Hulud 的蠕虫随后扩散到了 UiPath、DraftLab 和其他维护者的包。在一次异常严重的升级中，被感染的包携带了有效的 SLSA Build Level 3 provenance 证明，使这成为首个产生有效证明的恶意 npm 蠕虫。

这就是供应链攻击的新形态。它们非常快速。恶意版本进入注册表到被成千上万构建拉取之间的间隔通常是几个小时，有时甚至几分钟。它们能够自我传播，一个受感染的维护者会级联式地影响数十个包。而且它们绕过了大多数团队依赖的安全控制，因为当安全工具标记某个版本时，你的 CI 已经安装了它。

今天我们正式发布Secure Registry，这是 StepSecurity 的新产品，填补了这个时间差。

Secure Registry 是一个经过身份验证的上游注册表，位于你的开发者、CI 运行器和公共包注册表之间。每个元数据请求和 tarball 下载都会流经 Secure Registry，在返回响应前根据你配置的安全控制进行评估。违反控制的请求在安装时即被阻止或修改，无论安装是在 CI、开发者的笔记本电脑还是你的制品管理器中发生。

[iframe 嵌入内容]

为什么安装时强制执行很重要

目前行业中大多数供应链控制都是 Pull Request 控制。扫描器检查 manifest 和 lockfile 的变更，标记已知有问题的包，并使检查失败。当依赖通过经过审查的代码变更进入代码库时，这种模式运作良好，但实际上很多安装发生在该路径之外：

• 开发者本地运行 npm install，使用浮动的 semver 范围，拉取了不在 lockfile 中的新版本。
• CI 作业在全新检出上运行，解析依赖时不经过 PR 审查。
• 工作流中的临时脚本全局安装了一个工具。
• 新仓库从模板引导时，在任何 PR 控制配置之前。

这些都是 PR 阶段扫描无法看到的安装时事件。更糟的是，即使配置了 PR 控制，它们也只捕获已知有问题的包：已被报告、分析并添加到数据库的包。Mini Shai-Hulud 攻击的移动速度比该数据库更新速度更快。

Secure Registry 位于安装时层，对每个请求、每次都应用控制。相同的控制保护你的 CI 运行器、开发者的笔记本电脑和你的制品管理器，只需一个配置。

工作原理

Secure Registry 作为经过身份验证的代理，运行在 npm 注册表前方。集成模型故意设计得很简单。你不需要改变开发者或 CI 安装包的方式，只需要改变请求发送的目标位置。

1. 配置你的客户端。​ 将你的开发者的 npm 客户端、CI 运行器或制品仓库管理器（JFrog Artifactory、Google Artifact Registry）指向 Secure Registry URL 作为上游注册表。 [图片]

2. 请求流经。​ 每个 npm 元数据请求和 tarball 下载都会根据你启用的安全控制进行评估。 [图片]

3. 评估被记录。​ 每个请求及其评估结果都显示在你的 StepSecurity 仪表板的 Policy Evaluations 日志中。 [图片]

设置文档在应用的 Setup Guide 标签页下，有三条集成路径，取决于包如何到达你的环境：JFrog Artifactory、Google Artifact Registry 或直接 .npmrc 配置。Setup Guide 还包括一个简短的测试序列，用于确认你配置后请求是否正在流经 Secure Registry。支持主 API 密钥和次 API 密钥，以便你可以在不停机的情况下轮换凭证。

启动时的安全控制

Secure Registry 附带一组分层控制，你可以为每个生态系统切换开关。第一个控制 Cooldown Period 今天可用。另外两个即将推出。

Cooldown Period（可用）

阻止在可配置天数内发布的包，让社区和 StepSecurity 的 SOC 有时间在包到达你的环境前审查新版本。

Cooldown 是抵御零日供应链攻击最有效的第一道防线。原因在于结构层面：大多数恶意 npm 包在发布后 24 小时内被发现，要么是通过社区研究者，要么是通过像 StepSecurity 那样的自动化分析管道。数天的 cooldown 将发现窗口移出了你的安装窗口之外。到你的环境可以安装新版本时，它已经被看到、被扫描，并被确认为安全或标记为恶意。

Cooldown 窗口可配置。默认值为 10 天，我们推荐大多数环境使用。需要访问特定包最新版本的团队可以调整窗口、按生态系统划分 cooldown 范围，或将其与下面的其他控制配对使用。

当元数据请求被 cooldown 过滤时，Secure Registry 返回修改后的响应，移除最近的版本。客户端只能看到超过 cooldown 窗口的版本，依赖解析正常进行。不需要客户端更改。

Compromised Packages（即将推出）

阻止被 StepSecurity 的 SOC 和更广泛的安全社区标记为受感染或报告为恶意的包。Cooldown 将发现窗口移位，而 Compromised Packages 控制则作用于发现本身：确认恶意的包被直接阻止，即使它们在 cooldown 窗口之外。

Typosquatting Protection（即将推出）

阻止名称与流行包非常相似的包，防止 typosquatting 攻击，攻击者发布名为 lodahs 或 reqeusts 的包，等待某人 install 命令中的拼写错误。

Secure Registry 与 GitHub Checks 的比较

Secure Registry 补充而非取代 StepSecurity 现有的 GitHub Checks 控制，特别是 Package Cooldown 和 Package Compromised Updates，它们在 Pull Request 中扫描相同风险。两者在依赖生命周期的不同点强制执行：

同时使用两者可以提供分层保护。GitHub Checks 在风险被引入代码库时立即捕获，提供完整的 PR 上下文和明确的修复路径。Secure Registry 捕获其他所有内容：绕过 PR 审查的安装、带浮动版本的全新克隆、开发者的机器和临时工作流脚本。单靠任何一层都不足以应对 Shai-Hulud 和 Mini Shai-Hulud 所代表的风险模型；两者结合才能填补这个空白。

可用性

Secure Registry 今天向 Enterprise 客户可用，npm 支持已全面可用，PyPI 支持即将推出。如需开始，请在 StepSecurity 仪表板中打开 Secure Registry 页面，按照应用内 Setup Guide 操作。如果你尚未使用 Enterprise 层级且想要评估 Secure Registry，开始 14 天免费试用。

npm 生态系统不会自己变得更安全。像 Shai-Hulud 和 Mini Shai-Hulud 这样的蠕虫不是异常现象；它们是供应链攻击运作的新基准。

防御必须与攻击在同一层运作。在安装时，这意味着需要一个注册表级别的检查点——而如果你的管道没有这个检查点，你就一直依赖于完全的信任。