GitHub Actions 近期工作流治理应优先看哪些权限

GitHub Actions 工作流治理应优先看能改仓库内容、发布制品和接触部署凭据的作业，再看这些作业是否执行外部贡献者提供的代码。随后收敛 GITHUB_TOKEN 的授权范围，并单独管理其他凭据。没有在步骤中显式传入 token，不代表 action 就无法访问它。

官方地址：https://docs.github.com/en/actions/tutorials/authenticate-with-github_token

我更倾向于先按任务列出权限需求，再修改配置；这是一种治理判断，不是某次事故的复盘。本文依据当前官方文档讨论优先级，没有把常规文档包装成刚刚发布的新政策，也不声称 GitHub 近期统一改变了所有仓库的默认权限。

先确定需要保护的资产

以一个需要测试、打包和发布的项目为例，测试只需要取得源码，发布还会接触包仓库或部署环境。它们虽然都运行在 Actions 中，承担的业务后果却不同。把所有作业都赋予同样权限，会让普通测试步骤得到与发布任务相近的能力。

建议先列三类资产：仓库中的代码与协作记录、对外分发的制品、部署所需凭据。再为每个作业写一句“必须完成什么”。这比从一长串权限名称中随意删项更容易解释取舍。

再看不可信输入接触哪些权限

官方提醒，action 可以通过 github.token 上下文访问 GITHUB_TOKEN，即使工作流未把它显式作为输入传递。因此“我没有把 token 写进参数”不能代替最小权限设置。

另一个关注点是执行来源。外部提交的代码、工作流接收的文本和下载的产物，都需要明确其可信程度。官方安全指南特别提醒，具有较高权限的 pull_request_target、workflow_run 场景如果执行不可信 PR 内容，会扩大风险。治理时应先分清输入来源和执行内容，不应只看事件名称是否熟悉。

按写操作的后果安排优先级

这是本文按后果提出的排序，不是 GitHub 对所有组织规定的统一风险等级。生产部署、公共包发布与内部文档构建的实际优先级，应由组织资产价值决定。

把授权限制在需要的作业

GITHUB_TOKEN 可以在工作流层或单个 job 层通过 permissions 配置。官方建议尽量给予最低所需访问，并在必要的作业中增加权限。例如读取源码与创建 issue 是不同任务，不能因为某个通知步骤需要写 issue，就让整个构建链都获得不相关写权限。

还要识别凭据类型。permissions 控制 GITHUB_TOKEN，并不会同步缩减另存的个人访问令牌、GitHub App 凭据或第三方部署密钥。如果某个操作超出了 GITHUB_TOKEN 能提供的范围，应明确评估所选凭据的授权对象和生命周期，而不是用一个高权限共享 token 处理所有需求。

对于环境密钥，官方文档介绍了通过 required reviewers 保护访问的方式。它适合把发布责任落到具体人员，但不能替代作业内输入处理和依赖管理。本文没有操作任何仓库设置，也没有实际触发工作流。

记录凭据与负责人

每个使用凭据的 job 至少记录用途、权限依据、维护团队、引用的 action 和是否接收外部输入。这样后续删权限导致失败时，团队能找到对应的必要操作，而不是直接恢复全部授权。

记录中不要保存密钥本身。日志脱敏也不能作为暴露凭据的许可；官方指出自动遮蔽并非始终可靠。排障时应记录任务状态和必要上下文，避免把完整敏感内容当作普通诊断输出。

用问题清单检查治理结果

工作流负责人可以按下面的问题组织后续配置检查：这个 job 是否必须写仓库？是否必须取得发布凭据？是否执行不可信输入？每个额外凭据是否有独立负责人？测试与发布是否已经分开？失败处理是否会诱使维护者重新开放全部权限？

只把 token 放进 secrets 就够了吗？不够。保存位置与实际授权范围是两个问题，还要考虑谁能执行使用该凭据的代码。

只读 GITHUB_TOKEN 能限制所有外部系统吗？不能。第三方部署系统使用的密钥必须在相应系统和工作流中分别治理。

收紧权限后任务报错就应该全部恢复吗？应先定位具体失败操作，再补充必要能力；不要让一个局部缺权成为长期过度授权的理由。

官方安全使用参考：https://docs.github.com/en/actions/reference/security/secure-use。这份优先级安排适合整理历史工作流的团队；已有明确权限模型的组织应将其映射到现有制度，而非机械套用。