扫描 GitHub Actions 工作流 YAML 的…

当用户提供 .github/workflows/ YAML 或询问 GitHub Actions 安全加固时，直接阅读 YAML 并报告漏洞与具体修复，无需安装或运行外部工具。

适用场景

解决思路

1. 建立心智模型：每个 workflow 处于「特权 vs 非特权」与「可信代码 vs 不可信代码」的 2x2 中；只有「特权 workflow 运行不可信代码」这一格会发生妥协。特权 = 有 secrets、写权限或产出敏感产物（release、deploy、评论、标签）；不可信代码 = fork PR 作者可影响的内容：PR 源码、PR 标题/正文、提交信息、分支名、workflow 读取的文件、缓存、另一个不可信 workflow 产出的 artifact。不确定某值是否可信时，按不可信处理；误报成本只是审查评论，漏报成本是供应链妥协。
2. 对用户提供的每个 workflow 文件，按 Pass 1 到 Pass 9 顺序扫描；每一 pass 对应一类攻击。
3. Pass 1 危险触发器：检查 on: 块。立即标记 pull_request_target 为 P0（除非明确有正当理由）：它带 secrets 和写权限运行，可由 fork PR 触发，是经典 pwn-request 向量；即使不 checkout head，攻击者输入也会出现在 PR 标题、分支名、提交信息中并被插值。对每个发现：命名触发器，结合该 workflow 上下文解释危险，并提出改写（通常改为 pull_request，有时拆成两个 workflow，有时说明需要 GitHub App 而非 Actions）。
4. Pass 1 继续：标记 workflow_run 为 P0：与 pull_request_target 同样问题但间接，通过链式 pull_request workflow 的 artifact 或元数据。标记 issue_comment、issues、pull_request_review、pull_request_review_comment 为 P1：带 secrets 运行，任何能评论的人都可触达；仅当 workflow 不把用户可控字段插值进 shell 时才安全。标记 push 使用宽泛通配符（branches: ['*'] 或无分支过滤）为 P2：攻击者落地 PR 后可通过推送后续分支触发特权 workflow。
5. Pass 2 权限：检查 workflow 级和 job 级 permissions: 块。无顶层 permissions: 块 => P1；默认 GITHUB_TOKEN 权限取决于仓库和组织设置，老仓库可能是 write-all；建议在顶层加 permissions: {} 并按 job 授权。
6. 标记任意位置的 permissions: write-all => P1。
7. job 级 permissions: 授予明显超过该 job 需要的权限 => P2，例如只在跑测试的 job 上给 contents: write；建议最小权限。
8. 若与 Pass 1 危险触发器组合，严重级别提升一级。
9. Pass 3 action 固定：检查每个 uses: 行。固定到 tag（uses: actions/checkout@v4、@v4.1.1）=> P1；tag 可变，攻击者若攻陷 action 仓库可强推 tag。固定到 branch（uses: actions/checkout@main）=> P0，比 tag 更糟，该分支任意提交立即流入。
10. 固定到 SHA 但没有版本注释 => P3 风格问题；建议格式 uses: owner/action@<sha> # v4.1.1，便于审查 pin 更新。
11. 固定到 SHA 但看起来异常（第三方 action、可疑 owner、最近创建的仓库）=> 标记人工验证；没有 GitHub API 无法确认 impostor-commit 状态，但值得记录。
12. 对 tag/branch 固定的改写始终是：替换为预期版本完整 40 字符 commit SHA，并加 # vX.Y.Z 注释。
13. Pass 4 shell 注入（模板注入）：对每个 run: 块扫描 ${{ ... }} 替换。常量或非攻击者可控值通常没问题（如 ${{ matrix.os }}、${{ secrets.MY_TOKEN }}，尽管某些上下文仍有风险）。危险字段包括：github.event.pull_request.title、body、head.ref、head.sha、head.label；github.event.issue.title、body；github.event.comment.body、user.login；github.event.review.body；github.head_ref；github.event.workflow_run.head_branch、head_commit.message；github.event.commits.*.message、author.name、author.email；如果 workflow 在特权上下文运行，workflow_dispatch 的任意 inputs.*；以及最终来自 actions/github-script、下载的 artifact 或外部 API 响应的任意字段。
14. 检测规则：如果 run: 块直接在脚本体中包含 ${{ github.event.* }} 或 ${{ github.head_ref }}，即 P0 模板注入。修复始终是：把值放入 env，再在脚本中引用环境变量；示例 vulnerable: - run: echo "Branch is ${{ github.head_ref }}"；示例 safe: - env: BRANCH: ${{ github.head_ref }} 然后 run: echo "Branch is $BRANCH"。
15. 同时标记 P1：echo "VAR=${{ untrusted }}" >> $GITHUB_ENV —— 环境文件注入，攻击者可用换行逃逸变量；echo "::set-env name=VAR::${{ untrusted }}" —— 已废弃 workflow command，同样问题；内联脚本把不可信文件 cat 进 $GITHUB_ENV 或 $GITHUB_OUTPUT。
16. Pass 5 不可信 checkout：对每个 actions/checkout step 检查。若在 pull_request_target 或 workflow_run 触发的工作流中使用 ref: ${{ github.event.pull_request.head.sha }}（或 head.ref）=> P0，这是经典 pwn-request：特权上下文运行 fork 作者代码。
17. 若 persist-credentials: true（默认）出现在不需要回推的工作流上 => P2；除非工作流明确需要内嵌 token，否则建议 persist-credentials: false。
18. Pass 6 特权上下文中的缓存：对每个使用 cache: 输入的 step 检查（最常见于 actions/setup-node、setup-python、setup-go、setup-java 或直接 actions/cache）。缓存出现在 release 或 publish 工作流 => P0；来自默认分支上其他工作流的缓存投毒可把恶意构建输入流入 release；Trivy 和 TeamPCP 攻击都经此路由。
19. 缓存出现在处理 secrets 的工作流 => P1。缓存 key 未按作用域隔离，无法阻止不可信 PR 工作流写入与默认分支构建相同的 key => P2。
20. release 工作流的改写：完全移除 cache:，并加注释解释原因（例如 # Do not cache: see https://github.com/actions/setup-node/issues/1445）。
21. Pass 7 artifact 注入：如果工作流从另一个工作流下载 artifact（actions/download-artifact、dawidd6/action-download-artifact 等）：artifact 内容未经校验就用于 run: 或 $GITHUB_ENV => 若产出该 artifact 的工作流在不可信代码上运行（例如来自 fork 的 pull_request）则为 P0；攻击者可在 artifact 中放入任意内容。
22. 建议严格校验：若 artifact 本应是 PR number，拒绝任何非数字；若是结构化文件，解析并校验 schema。
23. Pass 8 release 专项加固：如果工作流像 release/publish 工作流（发布到 npm、PyPI、crates.io、Docker registry；创建 GitHub release；推送 tag）：publish job 未声明 environment: => P1；release 凭据应限定到 deployment environment，而不是 repo/org secrets。
24. 使用长期 registry token（secrets.NPM_TOKEN、secrets.PYPI_TOKEN）而非 OIDC/Trusted Publishing => P2；建议使用对应 registry 的 OIDC 路径。
25. 未生成 attestation（actions/attest-build-provenance、npm 的 --provenance、PyPI 的 PEP 740）=> P3 加固建议，不是漏洞。
26. release 路径中任何位置有缓存 => P0，见 Pass 6。
27. Pass 9 self-hosted runner：如果 runs-on: 使用非 GitHub 托管 runner（不是 ubuntu-*、windows-*、macos-*）：self-hosted runner 可被 fork PR 触达 => P0；self-hosted runner 跨 job 共享状态，曾导致严重妥协（PyTorch）。标记以人工审查 runner 作用域。
28. 这超出默认威胁模型：记录发现并建议用户在 GitHub 设置中验证 runner 限制。
29. 按固定结构报告每个发现，按严重级别分组，P0 在前：格式为 [P0] template-injection in .github/workflows/ci.yml:23；描述；Vulnerable: 代码；Fix: 代码。若用户粘贴原始 YAML 且没有文件名，称其为「the workflow」并使用片段内行号。
30. 严重级别定义：P0 = 当前可利用，无需链式利用；fork PR 作者或任意 GitHub 用户可妥协 secrets、仓库内容或 release；阻止合并。P1 = 需要额外一步可利用（例如需与其他发现组合，或需维护者失误）；若出现在 release 路径则阻止合并。P2 = 加固缺口；不能直接利用，但可与其他未来 bug 组合时降低爆炸半径；正常审查周期修复。P3 = 风格或一致性发现；值得为可读性修复，无安全影响。
31. 走完九个 Pass 后若没有命中：明确说「No findings against the standard rule set.」；说明没有检查什么：组织级设置（默认 token 权限、ruleset 强制、2FA）、仓库级设置（分支保护、tag 保护、immutable releases）、action 源码（固定 action 本身是否在运行时安装可变二进制），以及依赖的运行时行为；建议用户检查 references/checklist.md 中「Per repository」和「Per organization」项，这些需要 GitHub 设置访问权限而非 workflow YAML。干净的 workflow 扫描不等于干净的安全态势。
32. references/triggers.md：每个 GitHub Actions 触发器的详细表，说明各自危险/安全之处，以及人们常用危险触发器实现的常见安全模式；当 workflow 使用用户特别询问的触发器，或需要解释为何某触发器危险超过一行摘要时阅读。
33. references/checklist.md：扁平的 per-workflow / per-repo / per-org 清单；当用户要求完整审计、扫描大量仓库或大规模 triage 时有用；包含 triage 优先级顺序。
34. references/patterns.md：常见「我想安全地做 X」模式；当用户问如何替换已标记的危险模式，而不仅是识别它时阅读。
35. 不要安装 zizmor、pinact 或其他工具；扫描就是模型读取 YAML 并应用这些规则。
36. 除非用户明确问「该运行什么工具」，否则不要建议安装工具；即使那时，也直接指向模式——本技能中的规则就是那些工具编码的审计项。
37. 不要用缓解措施掩盖 pull_request_target 发现；如果 workflow 使用该触发器且不在 GitHub App 之后，就是开放发现。
38. 不要在未说明检查了什么和没检查什么的情况下告诉用户一切正常；对「这安全吗」的默认回答是「扫描覆盖了什么，以及发现了什么」。

适用边界 · 注意事项

• 不适用于非 GitHub Actions 的 CI/CD 系统，或需要实际运行外部扫描器/API 才能确认的检查（如 action 源码运行时行为、依赖运行时行为）。
• 不适用于仅靠工作流 YAML 无法覆盖的仓库/组织级设置（默认 token 权限、ruleset、2FA、分支/标签保护、immutable releases、GitHub 设置中的 runner 限制）与供应链运行时验证。
• 当用户明确要求安装/运行 zizmor、pinact 等工具时，不应用本技能替代其安装/执行；除非用户先问「该跑什么工具」，否则不要主动推荐安装。