GitHub 把供应链安全做成默认项：actions.lock 预览 + 推送保护默认拦截 Anthropic 密钥

10 月的第二周，GitHub 连着干了两件"把安全变成默认项"的事。10 月 14 日，GitHub Actions workflow lockfile 进入公开预览：以后 workflow 里引用的 action 会被锁死到确切的 commit，tag 再被移动也影响不了你的运行。10 月 13 日，secret scanning 的推送保护开始默认拦截两类 Anthropic API 密钥——在开了 secret scanning 的每个仓库里，含这两种密钥的提交会被自动拦下，免费的公开仓库也包括在内。两件事看起来不相干，其实是同一个转向：以前需要你手动做的供应链安全动作，正在变成默认配置或一键策略。

第一件事：actions.lock，把 workflow 依赖钉死在 commit 上

根据 GitHub 官方 changelog（发布时间 2026-10-14），GitHub Actions 的 workflow 依赖 lockfile 正式进入公开预览，覆盖 GitHub Enterprise Cloud（含 data residency 版本）、Team 和 Free 计划。页内还有一条 10 月 14 日当天更新的编者注，专门修正了适用计划——说明 GitHub 在发布当天还在调整这项预览的覆盖面。

它要解决的问题很具体，也很阴险：你在 workflow 里写 uses: actions/checkout@v4，审查的时候这个 tag 指向某个 commit；但 tag 和分支是可以移动的。审查通过之后、某次运行之前，如果有人（比如被入侵的 action 维护者账号）把 tag 挪到了另一个 commit，你的 workflow 就会在你毫不知情的情况下执行完全不同的代码。仓库本身没有任何变化，变的只是 tag 的指向。Lockfile 就是用来堵这个洞的：它让 workflow 文件里继续写人类可读的 tag，但实际运行时只认 lockfile 里记录的确切 commit。

用法上，GitHub 让你装一个 GitHub CLI 扩展 gh actions-lock（来自公开的 github/gh-actions-lock 仓库），用它生成和维护 .github/workflows/actions.lock 文件。这个扩展能做的事，changelog 列了四条：

• 钉死依赖：为 action 及其传递依赖、以及可复用 workflow 的依赖，生成带可审查 commit 的 lockfile。注意"传递依赖"四个字——你的 workflow 引用的 action 自己还引用了别的 action，这些间接依赖同样会被锁进去。这是很多人第一次意识到自己的 CI 依赖树有多深。
• 渐进接入：可以逐个 workflow 地 onboard。一旦某个 workflow onboard 了，它的所有依赖就必须在 lockfile 里有记录，GitHub Actions 只运行记录中的 commit。
• 运行一致性：即使 tag 或分支移动了，已 onboard 的 workflow 依然用锁定的 commit 跑。
• 检查过期：可以在不修改文件的情况下校验 lockfile 是不是过期了，适合放进 CI 里当一道检查。

配套的还有一个同样在预览中的 "Require lockfile" 策略：企业、组织和仓库三级管理员可以强制要求 workflow 使用 lockfile。这意味着大公司可以把"必须锁依赖"变成一条硬性规定，而不是靠每个仓库自觉。

和 Dependabot 的联动也想好了：当 Dependabot 给已 onboard 的 workflow 里的 action 开版本更新 PR 时，会在同一个 PR 里把对应的 lockfile 条目一起重新生成，让更新后的引用和锁定的 commit 保持同步，无需额外配置。更新依赖和更新锁，一次 PR 搞定——这个细节决定了很多团队愿不愿意真的用起来。

GitHub 的诚实 caveat：锁不等于安全

changelog 里有一句话值得全文引用，因为它决定了你该怎么理解这个功能："Locking does not determine whether the dependency itself is safe, so review dependencies before locking them."——锁定并不能决定依赖本身是否安全，所以在锁定之前先审查依赖。

这句话是在给 lockfile 划清能力边界：它防的是"依赖在你审查之后被偷换"，防不住"依赖本身就有问题"。如果你锁了一个已经被投毒的版本，lockfile 只会忠实地、一遍又一遍地运行那个投毒版本，而且因为"锁定了"给你一种虚假的安全感。正确的顺序永远是：先审查，再锁定。lockfile 保证的是"你审查过的代码"和"运行的代码"是同一份，它不负责替你做审查。

这个 caveat 和 AI Scan 那篇里的"供应链风险"检测类别放在一起看就很有意思：GitHub 的策略是组合拳——AI Scan 在 PR 里提醒你"这个第三方 action 没 pin"，lockfile 帮你把 pin 落实成机器可执行的记录，Require lockfile 策略再把它变成组织纪律。三层分别解决"发现问题"、"固定版本"、"强制执行"。单看任何一层都不完整。

第二件事：推送保护默认拦截 Anthropic 密钥

另一份 changelog（发布时间 2026-10-13）宣布：secret scanning 新增了来自 Salesforce、Anthropic 和 Cloudsmith 的几种密钥类型，其中两类 Anthropic 密钥被直接纳入推送保护的默认拦截名单。

具体来说，新增的检测类型是：anthropic_service_api_key（Anthropic 服务 API 密钥）、anthropic_user_api_key（Anthropic 用户 API 密钥）、cloudsmith_api_key，以及 Salesforce 的 salesforce_marketing_cloud_api_oauth2_token。其中两类 Anthropic 密钥进入了"推送保护默认包含"的检测器名单：在开启了 secret scanning 的仓库里（含免费的公开仓库），包含这些密钥的提交会被自动拦截，推不上去。

同一份公告还宣布 Salesforce 正式成为 secret scanning 的合作伙伴：当合作伙伴的密钥出现在公开仓库里，GitHub 会把它转交给发行方，以便在被滥用之前吊销或轮换。而 anthropic_user_api_key 这类用户密钥，则会在公开或私有仓库里产生 secret scanning 告警。检测、拦截、告警、通知发行方——GitHub 把这几件事分得很细：一次推送被拦下，不等于密钥已经被吊销；产生告警，也不等于有人已经轮换了它。

为什么是 Anthropic 密钥先被默认拦截？答案写在每个 vibe coder 的日常里：现在是个人开发者调用 Anthropic API 最多的时代，Claude Code、各种 agent 脚手架、.env 文件——密钥离 git 仓库的距离比以往任何时候都近。agent 写完代码顺手 git add -A 再 push，把 .env 一起推上去，已经成了新的经典事故形状。GitHub 把这两类密钥放进默认拦截，本质上是在给"agent 时代的工作流"打补丁：以前你要手动去开推送保护、手动加自定义模式，现在最常见的 AI 密钥类型开箱即拦。

但也要看清边界：默认拦截只发生在"开了 secret scanning 的仓库"。公开仓库默认有 secret scanning 私有仓库要看配置——你的私有仓库如果没开 secret scanning，这个默认保护就落不到你头上。推送保护拦的是 push 这一条路，它证明不了密钥没进过你的本地文件、终端历史、构建日志或者别的服务。一次被拦下的推送，应该被当作"有凭证进过版本控制"的证据来对待：轮换密钥、检查历史，而不是"拦下了就没事了"。

"默认安全"的转向：两件以前要手动做的事

把这两件事并排放，GitHub 的意图就很明显了。五年前，lock workflow 依赖意味着你要手动把每个 action 的 tag 换成 commit SHA，还要自己写脚本定期检查；拦截密钥推送意味着你要去仓库设置里打开推送保护，再为每种密钥写自定义正则。现在，前者变成了一个官方扩展加一个策略开关，后者对最常见的 AI 密钥变成了默认行为。

"默认安全"这四个字，安全行业喊了二十年，真正落地的标志就是"用户少做一步"。GitHub 这周的两个动作，恰好各让用户少做了一步：lockfile 让"钉死版本"从手工活变成 gh actions-lock 一条命令加一次提交；Anthropic 密钥拦截让"防密钥泄露"从配置项变成默认项。都不彻底——lockfile 还在预览，Require lockfile 还要管理员手动开，推送保护也只覆盖开了 secret scanning 的仓库——但方向是对的：把安全从"你要记得做"变成"你不关它就一直在"。

对 GitHub 自己的商业逻辑，这也是 Advanced Security 叙事的一部分：AI Scan 按 AI Credits 计费、lockfile 和推送保护强化平台粘性，安全功能正在从"卖 license"变成"卖持续运营"。管理员看板（上一篇文章里讲的 10-13 AI Scan 指标）加上 Require lockfile 策略，拼出来的是同一张图：让安全团队能量化、能强制、能审计。

给 vibe coder 的 CI 安全清单

如果你用 AI 写项目、CI 跑在 GitHub Actions 上，这周的两个更新可以直接变成一份检查清单，照着做一遍：

• 1. 给 workflow 上 lockfile：装 gh actions-lock 扩展，生成 .github/workflows/actions.lock，审查后提交。先从最重要的 workflow 开始，不用一次全上。
• 2. 先审查，再锁定：lock 之前看一眼你锁的是什么版本——锁住投毒版本比不锁更糟，因为给了你虚假的安全感。
• 3. 确认 secret scanning 和推送保护开了：特别是私有仓库。Anthropic 密钥的默认拦截只在开了 secret scanning 的仓库生效，"默认"不等于"全覆盖"，先去确认你的仓库在覆盖范围内。
• 4. 把 .env 写进 .gitignore，并且真的检查：推送保护是最后一道网，不是第一道。agent 的 git add -A 之前，确认 .env 没在里面。
• 5. 让 Dependabot 继续工作：它更新 action 时会自动同步 lockfile 条目，别因为上了 lockfile 就关掉依赖更新——锁死的旧版本和及时更新的版本之间，永远选后者加重新锁定。
• 6. 考虑 Require lockfile：如果你是组织管理员，在评估之后可以把它变成组织级策略，省得逐个仓库催。

清单很短，但每一项都在回答同一个问题：当写代码的是 agent、跑 CI 的是云端，哪些安全动作还必须有人（或有默认配置）来兜底。GitHub 这周的答案是：把版本钉死，把密钥拦下，剩下的审查，还是人的事。

来源

• GitHub Changelog：GitHub Actions workflow lockfiles in public preview（2026-10-14）
• GitHub Changelog：Secret scanning blocks Anthropic keys by default, adds Salesforce（2026-10-13）
• everydev.ai：Weekly AI Dev News Digest, October 10 – October 16, 2026（对 10-15 changelog 的引述）