OpenSSF Scorecard Dangerous-Workflow 怎样识别 GitHub Actions 风险

如果一个 GitHub Actions 工作流同时接收外部贡献、检出拉取请求代码，又能访问仓库写权限或密钥，风险重点就不在“有没有跑起来”，而在不可信内容能不能进入高权限执行路径。OpenSSF Scorecard 的 Dangerous-Workflow 检查，主要就是帮助发现这类工作流模式。

官方地址：https://scorecard.dev/

这项检查不能替团队做最终安全判断，但可以把复查范围收窄到触发器、检出对象、脚本变量和权限四个位置。下面按最小项目复查的顺序说明。

先看 Dangerous-Workflow 到底检查什么

Scorecard 官方文档把它定义为对 GitHub Actions 危险代码模式的检查，重点包括两条路径：

• 不可信代码检出：pull_request_target 或 workflow_run 这类工作流可能拥有目标仓库的写权限并访问密钥；如果随后显式检出由贡献者控制的拉取请求代码，构建脚本就可能进入高权限环境。
• 脚本注入：把攻击者可控的上下文变量直接拼进内联脚本时，变量内容可能被当成命令或脚本的一部分执行。

所以，看到检查结果时不要只问“分数是多少”，还要问“哪一个输入穿过了哪一个权限边界”。检查项能发现已知模式，却不能替代对标签审批、分支策略和工作流上下文的人工判断。

两类风险怎样对应到工作流写法

第一类风险通常不是某一行 checkout 单独造成的，而是“高权限触发器 + 不可信代码”组合出现。复查时先看 on 使用了什么事件，再看 actions/checkout 的 ref、repository 或 commit 是否来自外部拉取请求。若一个工作流既能读密钥，又把外部代码送进构建、测试或脚本步骤，就应把它拆成低权限验证和人工确认后的特权发布两个阶段。

第二类风险更容易被忽略。下面这种写法把 issue 标题直接嵌入 shell 字符串，标题中的特殊内容可能改变命令语义：

# 中文注释：不要把外部上下文直接插入 run 字符串
- name: 不安全的输出方式
  run: echo "${{ github.event.issue.title }}"

更稳妥的边界是让表达式只负责传递数据，再由固定程序按普通字符串读取。这样做不能自动消除所有脚本风险，但至少不会把标题当成 shell 源码拼接进去。

按 Scorecard 结果落到修复动作

1. 先标记输入来源：把 issue、评论、拉取请求标题、分支名等上下文值视为不可信数据，逐项记录它们流向了哪些 step。
2. 再标记权限：查看工作流和 job 级 permissions，把不需要写入的权限收紧为只读；不要因为某个后续步骤可能需要权限，就让前面的不可信代码一起继承。
3. 隔离外部代码：对外部拉取请求优先使用适合验证的低权限流程；需要发布或写入仓库时，另设受审批保护的工作流，不让外部代码直接进入同一执行上下文。
4. 区分信号和结论：Scorecard 报告说明检测到了某种模式，不等于已经证明仓库必然被利用，也不等于只改一处字符串就完成了修复。修复后要重新阅读触发器、检出对象和权限的组合。

用一个最小工作流做复查

下面的示例只做一件事：把 issue 标题作为环境变量传给固定程序，并明确声明只读内容权限。示例中的 Python 片段将标题按普通文本输出，不把它拼到 shell 语句中。

name: inspect-issue

on:
  issues:
    types: [opened]

permissions:
  contents: read # 中文注释：只保留当前任务需要的读取权限

jobs:
  inspect:
    runs-on: ubuntu-latest
    steps:
      - name: Read issue title as data
        env:
          ISSUE_TITLE: ${{ github.event.issue.title }} # 中文注释：先把外部值放入数据变量
        run: |
          # 中文注释：固定程序按普通字符串读取，避免标题成为 shell 语法
          python3 -c 'import os; print(os.environ.get("ISSUE_TITLE", ""))'

复查这段配置时可以按四个问题走一遍：触发事件是否真的需要特权？权限是否只在需要的层级声明？外部值是否只作为数据传递？有没有另一个 step 把同一个值再次拼回命令、路径或脚本？

常见问题

Dangerous-Workflow 分数低就一定已经被攻击了吗？

不一定。它说明检测到了需要人工复查的危险模式，实际影响还要结合触发条件、权限、代码来源和仓库保护措施判断。

只把 pull_request_target 改成 pull_request 就够了吗？

不能一概而论。还要检查是否仍然检出不可信代码、是否需要密钥、脚本是否接收外部上下文，以及发布步骤是否被正确隔离。

为什么环境变量传递更容易审查？

因为它把外部值和固定脚本分开，读者可以单独检查输入、程序参数和权限边界；这不是万能防护，但比直接插值更清楚。

总结一下，OpenSSF Scorecard Dangerous-Workflow 的实用读法不是盯着一个分数，而是沿着“触发器—代码检出—脚本变量—权限”追踪不可信输入。把外部代码放进低权限验证路径，把特权动作单独隔离，再把上下文值作为数据传递，才能让检查结果真正转化为可执行的修复清单。