固定第三方 Action 提交 SHA 的风险与运维挑战

把第三方 Action 固定到全长度提交 SHA，听起来像是个干净利落的安全答案。工厂流水线上拧螺丝，每颗螺丝都拧到规定扭矩，验收时按这个标准查，合格就是合格。可真正拧过的人都知道，扭矩到位不等于装配没问题，得看螺纹咬合、垫片状态、工具校准记录。固定 SHA 也是这样——它把“引用可变”这个口子堵上了，却顺手在运维那边推开另一扇门。

先看它解决了什么。用 @v3、@main 这类浮动标签，标签背后的代码可以在工作流文件一个字不改的情况下被换掉，代码审查记录瞬间失去参照意义。固定到全长度 SHA，相当于把这个第三方 Action 当成一次性快照使用，攻击者想往里面塞后门，得先制造一次看起来正常的提交历史，门槛明显抬高了。这是官方文档里说得很直白的一层好处。

麻烦出在后续。固定 SHA 之后，Dependabot 不会为这些 Action 创建告警，因为它只认语义版本控制。以前用 v3，版本升级有机器人帮忙盯着；现在一串哈希摆在那儿，人眼很难看出上游发了新版本、修了哪些漏洞。原本靠自动化兜住的一块，被静默地转嫁给了人工。

这还没完。哈希本身不承载语义信息，安全团队看到 actions/checkout@8f4b7…，没法像看 @v3 那样一眼判断它属于哪个大版本、有没有重大变更。每次上游发布更新、每个仓库要同步，都得人肉去查官方仓库、比对版本、决定要不要跟进。仓库一多，这件事就变成体力活，很容易被搁置，最后固定下来的往往是一个没人说得清老到什么程度的快照。

所以固定 SHA 不是终点，它只是把风险从“浮动标签可能被悄悄替换”转成了“固定值可能长期无人维护”。这两类风险没有谁更轻，只是发生在不同环节。务实来看，固定 SHA 仍然是值得做的基线动作，但得配上一套能撑住它的运维习惯：依赖项审查继续开着，让引用变化在合并前可见；定期人工复核固定值，把“该升级了”记进检查单；对高价值凭据设定轮换节奏，别让一个旧快照碰着敏感数据太久。固定 SHA 是对的，但把固定本身当成安全已经完成，就是下一个盲区。