GitHub 连续改 npm 和 Actions 的默认行为，前端团队会先感到疼，后端和运维也躲不开。包安装、发布账号、缓存权限、许可证审批，这些看起来分散的改动，其实都在指向同一件事，依赖变更正在被当成生产变更管理。
这不是坏事。只是很多团队的流水线还没准备好。
npm install 不能再全自动放行
npm v12 计划把一些安装动作改成显式允许。依赖里的 install 脚本、Git 依赖、远程 tarball，都不再默认一路通过。以前大家装包时经常只看 lockfile 有没有变，跑不跑脚本交给 npm 自己处理。这个习惯要改。
脚本被关掉以后，原生模块、代码生成、私有包准备动作都有可能受影响。团队要在升级前跑一遍安装演练，用 npm approve-scripts 看看哪些包需要脚本，再把允许清单写回 package.json。别等生产构建半夜失败。
高影响账号进入只读保护
GitHub 给 npm 高影响账号加了一个 72 小时只读保护。账号换邮箱或使用二次验证恢复码后，发布、管理 token、改包可见性、改组织成员这些动作会暂停。包还能下载，发布链路会被挡住。
这条规则会影响维护者，也会影响依赖这些包的企业。你的构建不会因为别人账号进入只读状态就立刻坏掉，但安全补丁、紧急发布和内部 fork 同步可能会慢下来。运维手册里要把这个延迟写进去。
Actions 缓存也进入最小权限
Actions 对不可信触发器发只读缓存 token，主要是堵缓存投毒。过去一些外部可触发的工作流能写默认分支缓存，后续受信任任务再恢复这些缓存，攻击路径就打开了。现在这类写入会被限制。
对团队来说，缓存策略要拆清楚。外部贡献者触发的检查可以读缓存，主分支或受信任发布任务再负责写缓存。速度会受一点影响，但换来的是生产密钥少暴露一条路径。这个账算得过来。
许可证检查会进入合并门禁
GitHub 的开源许可证合规预览，把依赖许可证从事后盘点往前挪到 Pull Request。企业可以用 ruleset 绑定许可证策略，新依赖不符合规则时，开发者要删除、替换、改策略或申请例外。
很多团队不怕漏洞扫描，怕许可证。因为漏洞通常有 CVE、版本和修复建议，许可证问题常常牵涉采购、法务和客户合同。把它放进合并门禁后，工程团队要提前约定谁能批例外，例外能放多久，哪些仓库先上策略。
把依赖变更当上线动作
优易云给客户做交付时，会建议把依赖升级纳入发布清单。新增包要看维护者、下载来源、许可证、安装脚本、是否需要原生编译、是否访问私有 registry。升级包要看变更范围、回滚版本、构建缓存和灰度计划。
这套检查不需要一开始就做得很重。可以先从核心仓库开始，给每个服务加一份依赖风险表。谁引入，为什么引入，有没有替代，出了问题怎么回滚。表格普通，但事故发生时很有用。
流水线演练要真实一点
建议团队准备一个分支，模拟 npm v12 的安装策略，关掉未批准脚本，限制 Git 和远程包来源，再跑全量构建、测试和镜像打包。失败项不要只修到能过，要记录原因。是包需要脚本，还是脚本其实早就没用。是私有 registry 配置不清，还是 lockfile 里混了旧地址。
供应链安全会落到流水线细节。哪个 token 能写，哪个任务能存缓存，哪个包能执行脚本，哪个许可证能进生产。细节清楚了，升级才不会变成猜谜。
