调研日期2026-07-30本文目标把 GitHub Actions 新增的可疑工作流执行前审批转成 Agent 参与提交、修改和发布时可执行的供应链防线。2026-07-28GitHub 宣布在 github.com 的公共仓库中某些被识别为潜在恶意的 GitHub Actions 工作流会在启动前被挂起必须由具写权限的协作者在已认证的 Web 会话中审核并批准后才会继续执行。该保护由 GitHub 自动应用不需要仓库额外配置公告同时明确它目前不覆盖 GitHub Enterprise Server。这是一条很重要的防线但它不是“打开自动化后就安全”的许可证。特别是当 Agent 能提交 PR、修改.github/workflows/*.yml、调用发布工具时安全边界应该从“事后看到告警”前移到“执行前能否获得能力”。一、先把公告能力和团队责任分开问题GitHub 本次已提供的能力团队仍必须做的事可疑工作流是否启动某些被识别为潜在恶意的工作流会被挂起等待写权限协作者批准把工作流文件的变更视作高风险代码审查对象是否需要开启公告称公共 github.com 仓库无需额外配置私有仓库、GitHub Enterprise Server 与自托管运行器仍要自行设计策略凭据保护执行前多了一道人工门默认最小化GITHUB_TOKEN把云凭据换成短期 OIDC隔离不可信 PR误报与漏报平台决定哪些运行被判定为可疑用允许列表、策略检查和发布环境审批兜住平台检测覆盖不到的路径工程推断这次变化说明 CI/CD 的防御重点正在从“扫描出风险后通知人”向“在工作流真正拿到 Token、Runner 和网络访问前阻断”移动。对 Agent 而言这是更符合现实的门槛模型可以提出变更但不能自动获得执行能力。二、Agent 参与 CI/CD 后威胁面多了一层“工作流即代码”传统代码审查主要看业务逻辑Agent 场景还要把下面这些变化单独标红Agent 生成 PR ├─ 改应用代码 → 常规测试、代码审查 ├─ 改依赖与 Action 引用 → 供应链校验、版本 / SHA 固定 └─ 改 .github/workflows/*.yml → 触发方式、权限、密钥、Runner、部署边界的专项审查最危险的不是一行显眼的rm -rf而是看似正常的能力组合把触发器改为pull_request_target、给工作流加入id-token: write、在不可信 PR 中 checkout 贡献者代码或让自托管 Runner 执行外部输入。它们单独看可能各有合理场景拼起来却能让不可信代码接触基础仓库 Token、组织机密或云角色。所以Agent 提交工作流变更的合理默认值应是测试可以自动运行权限升级和部署必须分离并等待人确认。三、四道门把“能提 PR”与“能影响生产”拆开Agent / 开发者提交 PR │ ├─ 门 1分支保护 工作流文件 CODEOWNERS 审查 ├─ 门 2无密钥、最小权限的 PR 静态策略检查 ├─ 门 3平台对可疑 workflow 的执行前审批公共 github.com └─ 门 4发布环境审批 短期 OIDC 云身份 │ ▼ 受控生产变更这里的关键不是堆很多扫描器而是让每一道门都减少一种能力审查门只有指定维护者可批准工作流路径的变更。策略门PR 检查不读 Secrets、不申请 OIDC只识别高风险差异并要求人工复核。执行门让 GitHub 的自动挂起成为公共仓库的额外刹车而不是唯一刹车。部署门生产权限只存在于批准后的部署 Job不把长期云密钥放回 PR 工作流。四、可运行示例对工作流变更做“无密钥”的专项检查把下面文件保存为.github/workflows/guard-workflow-changes.yml。它只在修改工作流文件的 PR 上运行默认只读仓库内容不读取 Secrets也不申请 OIDC。示例使用actions/checkoutv7以保持可运行生产仓库应按组织策略将第三方 Action 固定到已审核的完整 commit SHA。name: guard-workflow-changes on: pull_request: paths: - .github/workflows/** permissions: contents: read jobs: review-workflow-diff: runs-on: ubuntu-latest steps: - uses: actions/checkoutv7 with: fetch-depth: 0 - name: Flag high-risk workflow additions env: BASE_REF: ${{ github.base_ref }} run: | set -euo pipefail git fetch --no-tags origin $BASE_REF --depth1 diff$(git diff --unified0 origin/$BASE_REF...HEAD -- .github/workflows || true) printf %s\n $diff # 这是升级审查门不是完整的 YAML 安全分析器。 # 命中后让维护者审查而不是让 PR 自动获得高权限。 if printf %s\n $diff | grep -E ^\.*(pull_request_target|write-all|id-token:[[:space:]]*write|ACTIONS_ID_TOKEN_REQUEST_(URL|TOKEN)|secrets\.); then echo High-risk workflow change detected; maintainer review is required. exit 1 fi验证方式很直接在一个测试分支新增普通的pull_request工作流检查应通过再新增pull_request_target或id-token: write检查应失败。失败的含义是“需要专项审查”不是这些配置永远不能使用。如果确实有发布 Job再把它放进另一条只由受信事件触发的工作流例如workflow_dispatch、受保护的 tag 或发布事件并把权限收在 Job 级permissions: contents: read jobs: deploy: if: github.ref_protected true environment: production permissions: contents: read id-token: write # 只允许该部署 Job 向云提供方换取短期身份 runs-on: ubuntu-latest steps: - run: echo Authenticate with OIDC after the production environment is approvedid-token: write只允许 Job 请求 OIDC JWT本身不等于获得某个云资源的写权限真正的权限来自云侧对 issuer、repository、ref、environment 等声明的信任策略。因此云侧也必须把信任条件限制到受保护分支和指定环境。五、把平台保护接进组织策略而不是取代组织策略至少完成下面五件事将仓库或组织的默认GITHUB_TOKEN权限设为只读需要写入时在具体 Job 显式声明最小 scope。仅允许经过审核的 Action / 可复用工作流在能使用的范围内强制完整 SHA 固定避免 tag 被重指向。对.github/workflows/**配置 CODEOWNERS 与分支保护Agent 生成的这类 diff 不能由 Agent 自行批准。使用 GitHub Actions 的执行保护策略限制触发者与事件特别评估是否应限制或禁止pull_request_target。不让不可信 PR 使用自托管 Runner、生产环境或部署用 OIDC这些能力只在受保护 ref 的发布 Job 中开放。对于大型组织还应把“谁可以触发工作流”与“谁可以推送代码”区分开。GitHub 的 workflow execution protections 可以按 actor 和 event 做限制这能阻止“有写权限但不应执行 CI”的角色直接启动高权限流程。六、不要踩这四个坑1看到“需批准”就直接点通过审批应检查触发器、permissions、Secret 使用、Action 版本、Runner 类型和外联命令。它是一项变更审查不是积压任务的清除按钮。2在pull_request_target中 checkout PR 代码官方文档指出此事件以基础仓库的高信任上下文运行可能访问基础仓库 Token 与机密。除非你能明确证明不执行不可信代码否则用普通pull_request做测试部署移到独立工作流。3把id-token: write放在工作流根部这样所有 Job 都能申请 OIDC JWT。应把它只赋给真正需要云身份、且受环境审批保护的部署 Job。4用长期云 Secret 解决“审批后登录太麻烦”长期 Secret 一旦暴露审批只能保护“本次运行”保护不了凭据生命周期。优先让 OIDC 按 Job 换取短期、带条件的访问令牌。结语GitHub 对可疑工作流增加的执行前审批是供应链安全向“能力尚未发放时就拦住”迈进的一步。对 Agent 工程来说最该吸收的不是按钮本身而是这一条原则生成变更的能力可以广泛执行敏感动作的能力必须稀缺、短期、可审计。先用本文的无密钥 PR 检查为工作流 diff 加一道门再把部署权限收回到受保护环境和短期 OIDC。这样即使 Agent 写出了看似合理的 YAML它也无法单靠一次提交获得生产执行权。来源与延伸阅读GitHub Actions holds potentially malicious workflows for approvalGitHub 官方公告发布于 2026-07-28。GitHub Actions Security reference官方安全参考涵盖pull_request_target、OIDC 与 Secrets 风险。Workflow execution protections官方工作流执行策略说明。