题记与说明
- 标题: Secure use reference（原 Security hardening for GitHub Actions）
- 作者: GitHub Docs 官方
- 来源 URL: https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions（现 301 重定向至 canonical: https://docs.github.com/en/actions/reference/security/secure-use）
- 存档日期: 2026-11-03
- 标签: GitHub Actions, CI/CD 安全, 供应链安全, secrets 管理, Agent 系统, 权威参考
这篇讲什么
GitHub 官方的 Actions 安全权威参考（reference 类型，非教程）。旧名 "Security hardening for GitHub Actions"，现已重构为 "Secure use reference"，是一切实践文章的源头出处。全文四大板块：工作流编写（secrets 与脚本注入）、不可信代码 checkout（pwn request）、第三方 action 的供应链风险、GitHub 内置安全特性（runner 加固、审计、依赖监控）。
核心观点
- Secrets 自动脱敏不保证可靠：脱敏靠精确字符串匹配，所以永远不要把 JSON/XML/YAML 整块存成 secret（会大幅降低脱敏成功率）；secret 经 Base64/URL 编码或用于生成 JWT 后，要把变换结果也注册为 secret，否则日志照样泄露。
- 脚本注入的标准解法：优先用 action 而非 inline script；必须 inline 时，把
${{ github.event.pull_request.title }}这类不可信输入先塞进中间环境变量，让它只作为变量存在、绝不参与 shell 命令拼接。 pull_request_target/workflow_run是高危触发器：它们是特权工作流，一旦 checkout 不可信 PR 代码就可能被接管整个仓库。不必要就不用，必须用时严禁 checkout 不可信代码（可参考 GitHub Security Lab 的 "Preventing pwn requests"）。- 第三方 action 供应链：一个 action 被攻破 = 拿到你仓库全部 secrets + 可能的 GITHUB_TOKEN 写权限。最强防护是 lockfile（记录每个 action 的精确 commit、运行时校验源仓库身份，官方明确说它"取代 SHA pinning"）；用不了 lockfile 就 pin 全长 commit SHA（伪造需 SHA-1 碰撞），tag 只在信任作者时用，且无论如何都要审计源码。
- Self-hosted runner 几乎不该用于公开仓库：它不是一次性的干净 VM，可被 PR 恶意代码持久攻破；连私有仓库也要谨慎，因为任何有读权限的人都能 fork+PR。替代方案：REST API 创建 JIT 临时 runner（最多跑一个 job 就销毁）。
最值得记住的 2-3 个金句/数据
- "The best measure is to lock your workflow dependencies with a lockfile… This is the strongest protection available, and supersedes SHA pinning." —— SHA pin 已经不是最强方案了，lockfile 才是。
- "Self-hosted runners should almost never be used for public repositories." —— 以及那个细思恐极的细节：同一 runner 上的下一个 job 用
ps x -w就能看到上一个 job 以命令行参数传入的 secrets。 - 反直觉陷阱：Dependabot 只对语义化版本号的 action 报漏洞警报，SHA-pinned 的反而没有警报（line 275）——你为了安全做的 pin，会让你失去漏洞通知。
对我的启发
- AI 编程工具：AI agent 生成的 CI YAML 天然偏爱
@v3浮动 tag 和pull_request_target这类"能跑通就行"的写法。人工审查 AI 产出的 workflow 时，这份文档就是逐条 checklist：有没有 pin SHA/lockfile？有没有把 PR 标题直接插进 run 脚本？token 权限是不是默认只读？ - Agent 系统：pwn request 本质是 confused deputy——特权上下文消费不可信输入。这和给 agent 配工具权限是同一个问题：不要让持有高权限的执行体直接吞下外部不可信内容，权限分离（workflow_run 模式）比事后过滤可靠。
- 个人知识管理：这是典型的"源头 reference"——网上所有 Actions 安全实践文（pwn request 科普、SHA pin 教程）都指回这里。存一处原文，其他转述文章不必囤。
适合谁读
所有写 GitHub Actions workflow 的人（哪怕只写过一条）；接受 fork PR 的开源维护者（风险最高人群）；用 self-hosted runner 的团队；以及让 AI agent 自动生成/修改 CI 配置、需要一套审查底线的开发者。