你以为把密钥从源码里删了就安全了？今天 GitHub 把 Actions 日志里那行 console.log 也扫出来了

你的 CI/CD 流水线正在悄悄漏秘密。

不是仓库里的代码——是日志。GitHub 刚刚把这件事的根子彻底变了。

这个问题从哪来的

GitHub Actions 的日志会原样记录每一步的输出。你在 step 里写了 echo ${{ secrets.API_KEY }} 调试，生产跑完结果密钥进了日志。只要有人有这个 workflow 的读取权限，密钥就等于公开了。

更隐蔽的是间接泄露。你的脚本里可能有这样的代码：

curl -X POST https://api.example.com -H "Authorization: Bearer $TOKEN"

日志里这行请求会完整记录，包括 TOKEN 的值。你以为只是在调试网络请求，其实密钥已经写进去了。

这不是小众问题，这是大多数团队踩了都不知道的坑。

GitHub 现在怎么替你兜底

8月4日，GitHub 在公开路线图里把「Secret scanning detects secrets in Actions logs」推进了 Up Next 阶段。这条路线图 issue（github.com/github/roadmap/issues/1282）明确说了：日志里出现密钥，GitHub 会自动建 alert，不用你扫、不用你查，日志写进去的瞬间 alert 就出来了。

配套的是 8月7日的 secret scanning 覆盖更新，push protection 默认拦截新增了四个检测器：APIclub、Mistral AI、PostHog OAuth、Resend——连同已有的检测器，push 上去就会被拦在门外。

两件事叠在一起：日志里漏了自动告警，push 的时候默认拦截。密钥泄露的窗口从「不知道多久」变成了「几乎即时发现」。

你要做的一件事

检查你的 workflow 里有没有这种写法：

- name: Call internal API
  run: |
    curl -X GET https://api.internal/ping 
      -H "Authorization: Bearer ${{ secrets.INTERNAL_TOKEN }}"

改成一行的好处是调试方便，坏处是 token 值直接进了日志。改成这样：

- name: Call internal API
  run: node scripts/ping.js

把敏感信息的传递包进脚本，日志里只记录结果，不记录过程。这是目前最简单有效的缓解手段。

GitHub 的这条更新是 2026 年 CI/CD 安全里被低估的变化之一：攻击者早就在用 toJSON(secrets) 扫日志了，现在防守方终于也有了自己的自动发现机制。