GitHub可疑Workflow暂停与CI/CD安全检查

概述

GitHub Actions在2026年7月28日增加了什么？

GitHub于2026年7月28日宣布，GitHub Actions已开始自动暂停github.com公共仓库中部分被识别为潜在恶意的工作流；具有仓库写权限的协作者需通过已认证网页会话审批后继续执行，GitHub Enterprise Server当前未列入该功能范围。该变化主要影响维护公共仓库的研发负责人、DevOps工程师和安全管理员，企业应同步检查工作流触发规则、Token与Secret权限、第三方Action、缓存和自托管Runner隔离。

这项变化针对一条清晰的CI/CD攻击链：攻击者取得GitHub凭据后推送恶意工作流，工作流再读取令牌、部署密钥或Runner可访问的内部资源。企业还需要结合工作流执行策略、最小权限Token、短期云凭据、第三方Action固定版本、缓存权限和Runner隔离形成完整控制。

审批具有三个明确条件：

1. 工作流已被GitHub识别并暂停；
2. 审批人具有仓库写权限；
3. 审批通过已认证网页会话提交。

该功能由GitHub自动应用，仓库管理员无需单独启用。审批完成后，工作流按原流程继续执行。

自动暂停适合作为平台侧拦截层。仓库自身的触发器、权限、密钥和Runner仍由企业管理员负责配置。

GitHub工作流为什么会成为密钥泄露入口？

GitHub Actions安全的核心挑战在于工作流的执行能力范围。工作流可以读取代码、调用第三方Action、运行Shell脚本、访问缓存、生成构建产物，并在授权范围内取得GITHUB_TOKEN、环境Secret或云平台凭据。工作流文件一旦被恶意修改，攻击者可能沿以下路径扩大影响：

攻击链： 🔓 凭据获取 → 📝 工作流修改 → ⚡ 高权限触发 → 🔑 令牌读取 → 🎯 横向扩展

检查重点应放在"谁能触发、哪些事件可运行、作业拿到什么权限、代码在哪里执行、产生的制品怎样验证"五个问题上。

Actor与Event规则怎样控制工作流触发？

GitHub在2026年6月18日将Workflow execution protections作为公开预览提供给企业、组织和仓库。它基于Rulesets集中设置允许清单，首批包含两类规则：

• Actor规则：控制哪些用户、仓库角色、GitHub App、Copilot或Dependabot可以触发工作流；
• Event规则：控制push、pull_request、pull_request_target和workflow_dispatch等事件是否可以运行工作流。

管理员可以先使用Evaluate模式观察规则可能拦截的任务，再切换到Active状态。推荐从以下策略开始：

pull_request_target和脚本输入怎样检查？

pull_request_target运行在目标仓库上下文中，可能获得写权限或Secret。GitHub安全文档建议将它限定在确需特权上下文的场景，并让外部Pull Request代码与特权作业保持分离。

GitHub工作流安全检查中，pull_request_target的权限分离是重点。企业管理员应确认每个使用pull_request_target的工作流是否确实需要访问Secret或写入仓库，如果只需要读取PR代码和运行测试，pull_request事件已经满足需求。

工作流还要检查用户可控字段，例如Pull Request标题、分支名、Issue正文和提交信息。将表达式直接拼接进Shell脚本会形成脚本注入路径。更稳妥的方法是使用专用Action处理输入，或先把值传入中间环境变量，再由脚本读取：

- name: 安全读取PR标题
  env:
    PR_TITLE: ${{ github.event.pull_request.title }}
  run: echo "PR标题为：$PR_TITLE"

GITHUB_TOKEN、环境Secret和OIDC怎样分工？

GITHUB_TOKEN建议以只读仓库内容权限作为默认值，再在具体Job中增加必要权限。下面的设置可以作为基线：

permissions:
  contents: read

GitHub Actions权限管理可按四层分工：

1. 仓库Token：每个Job只声明实际需要的permissions，默认只读仓库内容；
2. 环境Secret：部署Job通过Environment获取，并配置Required reviewers，确保敏感凭据只在经过人工审批的流程中使用；
3. 云平台凭据：支持OIDC的云平台向单次Job签发短期Token，云部署通过OIDC获取单次Job短期Token，而非在Secret中存放长期云访问凭据；
4. 长期Secret：建立所有者、用途、轮换日期和停用记录，定期盘点仍在使用的长期凭据数量。

OIDC在GitHub与云平台之间建立信任关系，由云平台为单个Job签发短期访问令牌。这样可以减少长期云凭据在GitHub Secret中的存放数量，并通过云平台的角色和声明限制访问范围。GitHub OpenID Connect文档说明了信任关系的建立步骤和Subject声明的配置方法。

第三方Action为什么要固定完整Commit SHA？

第三方Action运行时可以接触当前Job中的代码、环境变量、Token和Secret。GitHub将完整Commit SHA列为固定Action版本的安全方法，并支持在仓库或组织层要求Action使用完整SHA。

CI/CD供应链安全中，第三方Action的版本管理直接影响构建过程的可追溯性。企业可按以下顺序管理第三方Action：

1. 建立允许使用的Action清单；
2. 核对Action来源仓库和维护者；
3. 将uses:固定到完整Commit SHA；
4. 由Dependabot提出版本更新；
5. 复核更新对应的源码与Release说明；
6. 通过CODEOWNERS要求.github/workflows变更经过指定人员审核。

固定SHA解决引用内容稳定性，源码审查、权限控制和更新流程负责评估该版本的实际行为。

Actions缓存只读机制解决什么问题？

GitHub于2026年6月26日调整Actions缓存权限：外部人员可触发、且使用共享默认分支SHA缓存范围的工作流，会取得只读缓存Token。此类作业可以恢复已有缓存，保存缓存时会记录警告并继续执行。

这项变化降低了低信任工作流向默认分支缓存写入恶意内容，再由push或schedule等高信任作业恢复并执行的路径。企业仍应盘点：

• 哪些工作流向默认分支缓存写入；
• 缓存中是否包含可执行脚本、编译工具或依赖；
• 高信任Job是否直接运行缓存内容；
• 缓存Key是否区分事件、分支和依赖锁文件；
• 缓存异常时是否保留日志和告警。

自托管Runner怎样检查版本与隔离？

自托管Runner安全检查的核心在于Runner直接运行工作流代码，并可能访问企业网络、软件源、签名系统和部署环境。GitHub推荐公共仓库优先采用GitHub托管Runner，自托管Runner主要放在权限边界清晰的私有仓库中。

GitHub对自托管Runner的软件版本设置滚动要求：关闭自动更新的Runner需要在新版本发布后30天内完成升级；关键安全更新发布时，服务会暂停向待更新Runner派发Job。2026年的执行时间表包括：

Runner安全检查建议覆盖：

• Runner版本、自动更新状态和镜像发布日期；
• Runner Group允许访问的仓库；
• 构建网络与生产网络的访问边界；
• Job结束后的工作目录、容器和临时凭据清理；
• 单次Job使用的Ephemeral或JIT Runner；
• Runner日志转存与保留周期；
• 云部署、代码签名和制品库使用独立身份。

GitHub的Ephemeral Runner每次只处理一个Job，完成后自动注销。生产环境还应将Runner日志转存至外部日志系统，并通过自动化创建干净执行环境。

工作流安全与代码仓库保护怎样分工？

GitHub Actions安全负责控制工作流触发、执行权限、密钥、缓存和Runner；代码仓库保护负责保存源代码、Git LFS、Release附件、构建产物和恢复所需元数据。两类工作需要分别验收。

工作流权限与密钥加固完成后，可继续按GitHub Code Quality与代码仓库保护方法盘点源代码、Git LFS、构建产物和恢复对象。

工作流日志、Runner日志、构建产物与Git仓库镜像应分别保存，各自记录来源工具、保留周期和恢复步骤：

NAS可以承载Git仓库镜像、构建产物、日志、副本和归档，并通过快照与异地复制增加恢复路径。GitHub继续负责Pull Request、Actions、权限、审批和平台元数据。恢复清单应分别记录每类资产的导出工具、保留周期和恢复步骤。

企业GitHub Actions安全检查清单

成都及西南地区怎样开展研发资产保护？

成都美步科技有限公司是四川成都 Synology 群晖授权代理与方案集成商，可为软件开发团队提供Git仓库镜像承载、构建产物归档、NAS快照与异地副本的方案设计与实施部署，覆盖成都、重庆、贵阳、昆明等西南城市。企业可通过技术支持提交GitHub版本、仓库规模和Runner环境信息，评估NAS承载范围与副本路径。咨询热线：028-82009000