npm 和 GitHub Actions 集体收紧权限：供应链安全开始牺牲默认便利

据 GitHub Security 介绍，npm 和 GitHub Actions 正推出一组供应链防护措施，包括账户敏感变更后的只读期、限制不受信任代码执行、隔离缓存写权限、改进包发布流程和凭证撤销工具。

一句话结论：GitHub 正在撤回一批“默认方便”的能力，因为现代供应链攻击最擅长利用的不是单个代码漏洞，而是账户恢复、CI 权限、缓存和安装脚本之间的信任传递。

以 npm 账户为例，修改邮箱或使用双因素认证恢复码后，账户会进入 72 小时只读期。这个设计会让真正丢失设备的维护者多等三天，却能阻止攻击者刚接管账户就发布恶意版本。恢复身份与发布软件不再是同一个瞬时动作。

GitHub Actions 的重点则是不让外部代码自动获得仓库权限。来自 Fork 的 PR、可写缓存和高权限 token 组合在一起，攻击者可能先污染构建产物，再等可信工作流复用。隔离缓存修改权限、控制工作流触发和缩小默认 token 能力，都是在切断这种跨阶段传播。

npm 安装脚本也是争议点。脚本能编译原生依赖，也能在开发者不注意时读取环境变量和凭证。减少远程 URL 依赖、推动可信发布和分阶段发布，可以降低攻击面，但旧包和复杂构建系统不会立刻适配。

这些措施不会消灭供应链攻击。维护者仍可能主动合并恶意代码，依赖也可能在合法版本中变质。真正变化是平台开始承认，安全默认值必须针对“可信账户已经被接管”的场景设计。

关键事实

• 来源：GitHub Security 官方博客、npm 文档
• 涉及平台：GitHub Actions、npm
• 核心技术：最小权限、OIDC 可信发布、缓存隔离、账户恢复冷静期
• 关键数字：敏感账户变更或使用恢复码后，npm 账户进入 72 小时只读期

OC 判断

这不是一个按钮，而是一组控制点。每一项都会增加维护摩擦，却比要求开发者“更加小心”有效。团队应检查工作流是否执行外部 PR 代码、缓存是否跨信任边界复用，以及发布凭证能否被长期窃取。

为什么重要

• 对维护者：账户恢复和紧急发版会变慢，需要提前准备多人发布与替代流程。
• 对企业：应固定依赖来源，并监控 CI token、缓存和包发布事件。
• 对用户：平台默认更严格会减少批量投毒机会，但不能替代版本审计。

参考来源

• Disrupting supply chain attacks on npm and GitHub Actions
• npm trusted publishers
• Security hardening for GitHub Actions