gha-security-review

GitHub Actions 安全审查

查找 GitHub Actions 工作流中可被利用的漏洞。每项发现都必须包含具体的利用场景——如果无法构造攻击，就不要报告。

此技能汇总了真实 GitHub Actions 漏洞利用中的攻击模式，而非泛泛的 CI/CD 理论。

范围

审查提供的工作流（文件、差异或仓库）。根据需要研究代码库，以便在报告前追踪完整的攻击路径。

待审查文件

• .github/workflows/*.yml — 所有工作流定义
• action.yml / action.yaml — 仓库中的组合操作
• .github/actions/*/action.yml — 本地可重用操作
• 工作流加载的配置文件：CLAUDE.md、AGENTS.md、Makefile、.github/ 下的 shell 脚本

不在范围内

• 其他仓库中的工作流（仅注明依赖关系）
• GitHub App 安装权限（如相关，请注明）

威胁模型

只报告可被外部攻击者利用的漏洞——即没有仓库写入权限的攻击者。攻击者可以从 fork 创建 PR、创建 issue 并发表评论。他们无法推送到分支、触发 workflow_dispatch 或触发手动工作流。

不要标记需要写入权限才能利用的漏洞：

• workflow_dispatch 输入注入——触发工作流需要写入权限
• 仅限受保护分支上的 push 工作流中的表达式注入
• 所有调用方均为内部调用方时的 workflow_call 输入注入
• 仅由 workflow_dispatch/schedule 触发的工作流中的密钥

置信度

只报告置信度为高和中的发现。不要报告理论上的问题。

置信度	标准	处理方式
高	已追踪完整攻击路径，并确认可利用	报告并提供利用场景和修复方案
中	部分确认攻击路径，但存在不确定环节	报告并标记为需要验证
低	理论上的问题，或已在其他位置缓解	不要报告

对于每项高置信度发现，请提供以下全部五项内容：

1. 入口点——攻击者如何进入？（fork PR、issue 评论、分支名称等）
2. 载荷——攻击者发送什么？（实际代码/YAML/输入）
3. 执行机制——载荷如何运行？（表达式展开、检出代码后执行脚本等）
4. 影响——攻击者能获得什么？（窃取令牌、执行代码、仓库写入权限）
5. PoC 概述——攻击者会遵循哪些具体步骤

如果无法构造完整的五项内容，则报告为中等置信度（需要验证）。

---

步骤 1：分类触发器并加载参考资料

对于每个工作流，识别触发器并加载相应的参考资料：

触发器 / 模式	加载参考资料
pull_request_target	references/pwn-request.md
带命令解析的 issue_comment	references/comment-triggered-commands.md
run: 块中的 ${{ }}	references/expression-injection.md
PAT / 部署密钥 / 高权限凭据	references/credential-escalation.md
检出 PR 代码并加载配置文件	references/ai-prompt-injection-via-ci.md
第三方操作（尤其是未固定版本的操作）	references/supply-chain.md
permissions: 块或密钥的使用	references/permissions-and-secrets.md
自托管运行器、缓存/制品的使用	references/runner-infrastructure.md
任何已确认的发现	references/real-world-attacks.md

有选择地加载参考资料——只加载与发现的触发器相关的内容。

步骤 2：检查漏洞类别

检查 1：Pwn Request

工作流是否使用 pull_request_target 并检出 fork 代码？

• 查找 actions/checkout 中指向 PR 头部的 ref:
• 查找来自 fork 的本地操作（./.github/actions/）
• 检查是否有任何 run: 步骤执行检出的 PR 中的代码

检查 2：表达式注入

可由外部触发的工作流是否在 run: 块中使用了 ${{ }} 表达式？

• 列出每个 run: 步骤中的所有 ${{ }} 表达式
• 确认值由攻击者控制（PR 标题、分支名称、评论正文，而非数字 ID、SHA 或仓库名称）
• 确认表达式位于 run: 块中，而非 if:、with: 或作业级 env:

检查 3：未经授权的命令执行

由 issue_comment 触发的工作流是否会在未经授权的情况下执行命令？

• 是否检查了 author_association？
• 任何 GitHub 用户都能触发该命令吗？
• 命令处理程序是否也使用了可注入的表达式？

检查 4：凭据提升

不受信任的代码是否可以访问提升权限的凭据（PAT、部署密钥）？

• 每个密钥的影响范围有多大？
• 被入侵的工作流能否窃取长期有效的令牌？

检查 5：配置文件投毒

工作流是否会加载 PR 提供的文件中的配置？

• AI Agent 指令：CLAUDE.md、AGENTS.md、.cursorrules
• 构建配置：Makefile、shell 脚本

检查 6：供应链

第三方操作是否安全地固定到了完整 SHA？

• 仅固定第三方 / 外部操作和可复用工作流
• 不要将使用版本标签的第一方 actions/* 或 github/* 标记为问题
• 不要将同仓库 / 供应商化操作（./.github/actions/...）标记为供应链固定问题
• 仅当作业具有密钥、OIDC、写入令牌、发布、部署、打包或签名权限时才报告——不具备权限的只读 CI 不构成发现

检查 7：权限和密钥

工作流权限是否遵循最小化原则？密钥是否正确限定了范围？

检查 8：运行器基础设施

自托管运行器、缓存或制品是否安全使用？

安全模式（不要标记）

报告前，请先检查该模式是否实际安全：

模式	安全原因
pull_request_target，且未检出 fork 代码	永远不会执行攻击者的代码
run: 中的 ${{ github.event.pull_request.number }}	仅为数字，不可注入
${{ github.repository }} / github.repository_owner	仓库所有者可控制该值
${{ secrets.* }}	不是表达式注入向量
if: 条件中的 ${{ }}	由 Actions 运行时求值，而非 shell
with: 输入中的 ${{ }}	作为字符串参数传递，不由 shell 求值
固定到完整 SHA 的第三方操作	不可变引用
使用版本标签的第一方 actions/* / github/*	不在第三方固定策略范围内——不要标记
同仓库 / 供应商化本地操作	不属于第三方供应链（需单独审查 pwn-request）
pull_request 触发器（而非 _target）	在 fork 上下文中运行，使用只读令牌
workflow_dispatch / schedule / push 到受保护分支时使用的任何表达式	需要写入权限——不在威胁模型范围内

关键区别： ${{ }} 在 run: 块中存在危险（shell 扩展），但在作业 / 步骤级别的 if:、with: 和 env: 中是安全的（由 Actions 运行时求值）。

步骤 3：报告前验证

纳入任何发现之前，请阅读实际工作流 YAML，并追踪完整攻击路径：

1. 阅读完整工作流——不要只依赖 grep 输出
2. 追踪触发器——确认事件，并检查控制执行的 if: 条件
3. 追踪表达式 / 检出操作——确认表达式位于 run: 块中，或确实引用了 fork 代码
4. 确认攻击者可控——验证该值对应外部攻击者可以设置的内容
5. 检查现有缓解措施——环境变量包装、author_association 检查、受限权限、SHA 固定

如果攻击路径中的任何环节不成立，请将其标记为 MEDIUM（需要验证），或删除该发现。

如果检查未发现问题，则报告零项发现。不要凭空捏造问题。

步骤 4：报告发现

## GitHub Actions Security Review

### Findings

#### [GHA-001] [Title] (Severity: Critical/High/Medium)
- **Workflow**: `.github/workflows/release.yml:15`
- **Trigger**: `pull_request_target`
- **Confidence**: HIGH — confirmed through attack path tracing
- **Exploitation Scenario**:
  1. [Step-by-step attack]
- **Impact**: [What attacker gains]
- **Fix**: [Code that fixes the issue]

### Needs Verification
[MEDIUM confidence items with explanation of what to verify]

### Reviewed and Cleared
[Workflows reviewed and confirmed safe]

如果没有发现：「未发现可利用的漏洞。所有工作流均已审查并确认安全。」