npm经典令牌被撤销 — 全栈团队的紧急迁移清单

发生了什么（简短）：GitHub的npm注册表于2025年12月9日完成了一项计划中的安全强化——所有遗留的“经典”npm令牌被永久撤销，针对本地登录引入了基于会话的身份验证，并支持创建/管理细粒度访问令牌的CLI功能。这会破坏任何仍依赖于长期存在的经典令牌的工作流（CI密钥、预构建镜像、部署脚本、内部工具）。 (github.blog)

这对全栈团队的重要性

• 发布/管道中断：注入经典NPM_TOKEN的CI作业现在将因身份验证错误而失败，通常在发布流程中默默发生。 (github.blog)
• 增加轮换和双因素身份验证纪律：细粒度写入令牌默认是短期的，并强制执行更强的双因素身份验证/绕过规则用于自动化——您需要令牌轮换/证明或基于OIDC的发布。 (github.blog)
• 隐藏凭证：嵌入到容器镜像、构建缓存或开发者机器中的令牌停止工作，可能需要在多个地方进行修复（镜像、云密钥、~/.npmrc）。 (github.blog)

现在该做什么 — 优先级清单（今天就执行）

1. 分类：查找所有经典npm令牌的使用

• 在GitHub/GitLab/CI密钥中搜索NPM_TOKEN、npmrc文件、Dockerfile和构建脚本。不要忘记自托管的运行器和云镜像。这是影响最大的单一步骤。 (github.blog)

2. 恢复CI发布（快速恢复）

• 如果您从GitHub Actions或GitLab发布，请在支持的情况下采用“可信发布”/OIDC——它通过为每个工作流运行发放短凭证来消除存储的长期令牌。如果OIDC不可行，请创建一个具有最小所需范围的细粒度访问令牌，并为该令牌启用CI的“绕过双因素身份验证”选项。测试一次排练发布。 (github.blog)

3. 轮换密钥和镜像

• 用新的细粒度令牌替换任何NPM_TOKEN密钥或转向OIDC。重建并重新部署任何包含经典令牌的容器镜像或虚拟机镜像。轮换后审计CI日志以查找401/403失败。 (github.blog)

4. 本地开发者工作流更新

• 教育工程师：npm login现在为交互式发布生成短期（2小时）会话；对于长期运行的本地任务，请使用细粒度令牌或在可用时采用开发时间OIDC。从~/.npmrc中删除长期存在的令牌。 (github.blog)

5. 更新工具和注册表

• 私有注册表/代理设备：确认它们支持细粒度令牌和会话身份验证。如果您依赖于旧的包管理器（Yarn v1/v2），请注意在推出期间临时恢复了一个遗留端点——计划升级，因为该兼容层是短期的。 (github.blog)

6. 自动化轮换和最小权限

• 实施令牌轮换策略（自动续订或短TTL），将令牌范围限制为“仅发布”或只读（如可能），并在包和组织级别强制执行最小权限。将轮换集成到您的秘密管理器中（Secrets Manager、Vault、GitHub Secrets + OIDC）。 (github.blog)

7. 迁移后验证

• 从CI和本地开发机器上运行完整的发布干运行。确认npm publish、npm pack和npm dist-tag按预期工作，并且包的来源（如可用）由可信发布/OIDC记录。

快速修复行动手册（最小命令/步骤）

• 审计：在仓库和镜像中使用grep/secret-scan查找NPM_TOKEN。
• CI：将发布作业切换为使用OIDC（GitHub Actions：配置id-token权限 + npm设置中的可信发布者）或创建具有确切范围的细粒度令牌 + 仅用于CI的绕过双因素身份验证。 (github.blog)
• 本地：指示开发人员运行npm login并从~/.npmrc中删除遗留令牌；优先使用临时会话或按任务的细粒度令牌。 (github.blog)

操作中的陷阱和注意事项

• Monorepos和工作区脚本通常重用单个令牌——轮换该一个密钥可能会同时影响数十个包。分阶段推出并进行排练发布。 (github.blog)
• 嵌入令牌的CI镜像或构建缓存必须重建；否则，即使在密钥轮换后，管道也会失败。 (github.blog)
• 一些第三方服务或旧工具可能仍然期望经典令牌；需要逐个供应商检查。 (github.blog)

为什么这值得付出努力 这一变化实质上减少了泄露长期凭证的影响范围，强制实施更好的自动化卫生（OIDC/可信发布），并使npm注册表与更强大、现代的身份验证模式保持一致——但这需要仍依赖于遗留令牌的团队立即进行操作工作。 (github.blog)

进一步阅读（官方变更日志）

来源

• Source