你以为 GitHub Actions 的 Secrets 就是一个 Key-Value 配置？写错过一次你就懂了

很多团队把 GitHub Actions 的安全理解成「把密钥塞进 Secrets 里」这一件事。这不是加固，这只是把钥匙换了个抽屉。

2026 年这条链路已经发生了三件值得注意的事：GitHub 默认把 pull_request_target 上常见的 pwn request 模式堵住了；OIDC 的 subject claim 开始绑定不可变仓库 ID，命名回收攻击失效了；7 月底上线的 Actions network firewall 把 runner 的出站流量放进了技术预览。

这些都不是独立的安全补丁，它们指向同一个结论：CI/CD 正在从「自动化脚本」变成「关键执行环境」，信任边界必须重新设计。

你真正该防的不是「别人拿到 Secret」，而是「别人拿到 Secret 之后能干什么」

TanStack 供应链事件把这串攻击链拆得很清楚：一个合并进 pull_request_target 工作流的恶意 PR、一份被污染的主分支缓存、一次从 runner 内存里直接提取的 OIDC token——三步之内，攻击者拿到了云凭证，并以此发布了 84 个恶意包。整件事的核心不是「密钥泄露」，而是工作流上下文里的默认信任太宽。

Datadog Security Labs 同期给出过一个数字：38% 的团队至少存在一个可被脚本注入利用的 Actions workflow。对大多数人来说，这不是「有没有问题」的问题，而是「什么时候会暴露」的问题。

五件能立刻落地的加固动作

1. 依赖锁定，优先把 Actions 固定到完整 commit SHA。 浮动 tag 可以在一次 force push 之后指向完全不同的代码。你的构建需要确定性，你的依赖引用也需要。
2. 撤销 pull_request_target 上的不受信任检出。 如果不需要它，换成 pull_request；如果确实需要，用 actions/checkout@v7 并显式设置 allow-unsafe-pr-checkout 作为 deliberate decision，而不是默认行为。
3. 把 OIDC 的 sub 条件钉死到 repo + branch + workflow。 不要给 org 开通通配符。对新建仓库，July 15 之后的 immutable subject claims 已经默认带上 owner/repo ID；现有仓库应该主动 opt in 并同步更新云厂商 trust policy。
4. 按环境隔离 Secret，把「写代码」和「管密钥」拆成两个权限。 GitHub 正在把 secret management 从 repository write 里拆出来，提前把生产和预发环境锁在各自的 Environment Protection Rules 后面。
5. 先开 Actions network firewall 的监控模式，再考虑强制执行。 现在还在 technical preview，但它会把 runner 的出站请求自动关联到 workflow run / job / step / 触发命令。先看一周流量清单，再决定 allowlist。

结论

2026 年的 GitHub Actions 安全，核心已经从「秘钥藏好」变成「信任边界明确」。依赖锁定、事件触发器审计、OIDC subject pinning、环境保护、出站网络观察——这五件事不需要等 GA，今天就可以在测试仓库里跑一遍。

下一步可以立刻做的三件事

1. 扫描仓库里所有使用 pull_request_target 的工作流，列出谁需要它、谁可以换成 pull_request。
2. 检查云厂商 trust policy 里的 sub 条件，去掉 org 级通配符，更新到 immutable repo ID 格式。
3. 对生产环境启用 Environment Protection Rules，至少设置 required reviewers + branch restriction，不要给所有协作者自动放行。