写过 CI 的人都踩过这个坑——等恶意 workflow 跑起来了才知道它不对劲，今天 GitHub 把这件事从根上截了

你有没有过这种经历——CI 跑得好好的，突然发现某个 workflow 在干一件完全不认识的事：它试图把所有 secrets 打印出来，或者偷偷往外部发网络请求。问题是，等你发现的时候，workflow 已经跑完了，凭证已经外泄了。

2026 年 6 月，一个叫 tj-actions 的流行 action 被植入恶意代码，23000 多个仓库的 CI 凭证在那次供应链攻击中泄露。攻击者利用的就是”workflow 进来就跑，没人在意”的盲区。

GitHub 在 7 月 28 日上线的这个功能，就是专门堵这个口的。

GitHub Actions 现在会自动暂停它认为”可疑”的 workflow 执行。所谓”可疑”，指的是 GitHub 系统检测到某个 workflow 的行为模式跟已知的供应链攻击手法相似——比如首次接触敏感资源、尝试在非预期时间发起网络请求、或者访问跟这个仓库正常业务无关的云服务。暂停之后，workflow 不会立刻跑，它会等在那里，直到一个拥有写权限的协作者在 GitHub.com 的网页端手动点了批准。整个过程不需要你装任何东西，不需要改一行配置，GitHub 自动给你加上这道门。

为什么这件事重要？看一下 CI 环境里有什么就知道了。部署密钥、包发布凭证、云服务临时 Token、npm/pypi 发布权限——这些东西正常 workflow 需要，攻击者更需要。以前攻击链是这样走的：账号被黑 → 改 workflow 文件 → credential 提取 → 外泄。从账号被黑到凭证出去，整个过程是自动化的，没有停顿。现在多了这道审批门，攻击者把 workflow 塞进来了，runner 不会直接跑，协作者会收到通知，有机会在造成损失之前把它掐掉。

这个功能目前只覆盖 github.com 上的公共仓库，GitHub Enterprise Server 还没上。GitHub 没有公开具体的检测规则细节，但从 6 月的 tj-actions 事件到现在的响应速度看，这套检测机制应该是基于实际攻击模式的 pattern matching 而不是简单规则。GitHub 的说法是：这是你整个供应链安全策略里的一层，不是全部。最稳的组合还是最小权限 token、受保护的环境变量、以及对 workflow 文件变更的 CODEOWNERS 审核。

落到工程实践上，有两件事值得现在做。第一，把 workflow 文件本身当代码一样审，CODEOWNERS 配到位，别让随便一个人都能开 PR 改你的 CI 配置。第二，既然 GitHub 已经能检测异常行为了，你作为协作者，遇到 workflow 被暂停的情况，不要直接点通过——看清楚是谁触发的、event 来源是什么、权限申请范围是否合理，这三件事确认完了再放行。

GitHub 说他们 2026 年的 roadmap 里还有 workflow 依赖锁定、原生 Layer 7 出口防火墙、以及 per-job 级别的 secrets 隔离。这些如果上了，CI 安全就能从”事后告警”变成”事前阻断”。但在那之前，可疑 workflow 审批门已经是免费又零配置的一道硬防线。