GitHub 供应链受到多次打击后，对 npm 和 Actions 采取了更严格的措施

用简单的语言来说 - GitHub 在经历了数月高调的供应链攻击后，正在向 npm 和 GitHub Actions 发送一批增强安全性的更改。签名发布、收紧令牌、更严格的工作流隔离。对于懒惰的管道来说可能会很痛苦，但值得。

背景

npm + GitHub Actions 的组合集中了 JavaScript CI/CD 的绝大部分份额 - 因此也集中了越来越多的针对性攻击，特别是通过维护者令牌的妥协。GitHub，这两个平台的所有者，于2026年7月28日发布了一篇关于过去几个月内“已发布的更改”的回顾文章。这一举措是在更广泛的访问加固范围内进行的（也可以看到，2026年9月2日开始对所有提交的开发者实施2FA义务 - 公告#1400）。

数据

根据官方文章（github.blog/security），防御措施涵盖三个方面：

• npm - 签名发布（证明），对令牌的限制，加速撤销。
• GitHub Actions - 工作流之间的隔离加强，秘密管理加固。
• 主动采取的对策，针对已经在生产环境中观察到的攻击技术。

幕后

具体来说，维护者现在可以从签名的 Actions 工作流中发布，并附带可验证的证明。这打破了“包已签名但推送到仓库外部”的攻击类别：包与原始提交之间的可追溯性变得可审计。

分析

有三个信号需要记住。首先，攻击面从仓库滑向了管道：妥协一个维护者令牌或CI运行器现在比直接访问源代码提供了更多的东西。其次，GitHub 正在平稳地行动 - 新规则与旧模式共存，逐步迁移，没有突然的中断。最后，占主导地位的平台实际上在强加其教义：GitLab、Bitbucket 和 Sonatype 生态系统必须跟上或失去企业信誉。

场景（12个月）

• 基准情况 - 大型消费者（银行、国防）在其SBOM中要求证明；通过合同传播，而非法律。
• 上行风险 - 一个重大事件绕过新防御（自托管运行器配置不当，实践中仍然宽松）。
• 实际阻力 - 维护者方面的惯性：在12个月内，前1000名包裹中仍有大多数未签名。

对从业者的影响

对于后端负责人：从Actions配置受信发布，在发布工作流中启用证明。对于平台工程师：检查您的自托管运行器，通常比托管的GitHub运行器加固较少。对于CISO：在客户要求之前，将证明验证添加到您的发布管道中。

关注点

在未来几个月内，关注npm顶级包的证明计数器，记录硬化后的首次已记录攻击尝试，以及PyPI和Cargo是否与同一模式保持一致（或不一致）。