GitHub Actions 引入第三方 Action 前，先检查版本固定与权限

一段简短的 uses 配置可能引入大量外部代码。评审第三方 Action 时，不能只看使用人数或工作流是否通过，还应弄清它能接触哪些代码、凭证和部署目标。

版本可重复只是第一步

GitHub 官方安全文档建议把 Action 固定到完整提交 SHA，并验证该提交来自预期仓库；标签可能移动。固定版本能减少未经审查的变化，但不会自动证明该版本本身安全，仍需检查来源与代码行为。

为每个任务写出权限理由

把测试、打包和部署拆成不同权限范围。只读测试任务通常不应拥有发布包、写仓库或修改云资源的凭证。逐项检查 GITHUB_TOKEN 权限、显式传入的秘密以及运行器上预先存在的环境配置。

• 输入：是否把不可信的分支名、标题或用户内容直接拼接进命令。
• 输出：是否把秘密、环境变量或包含凭证的 URL 写入日志和产物。
• 依赖：Action 是否在运行时下载额外脚本或使用未固定的镜像。
• 触发：外部贡献者的代码会在哪种事件和权限下执行。

验收要覆盖权限不足的情况

在测试仓库验证正常构建，并确认不需要的写操作确实被拒绝。高权限发布步骤应只接受可信来源的产物及符合规则的触发条件；不能因为工作流失败，就把所有权限改成可写。

为固定版本建立更新流程，定期审查上游变更与安全公告，避免固定后永不升级。自托管运行器还需要隔离与清理策略，防止前一次任务留下的状态影响后续任务。

评审结果应保留 Action 来源、提交标识、所需权限和批准用途。这样在依赖出现问题时，可以快速定位受影响的流水线。

参考：GitHub：Secure use reference。核对日期：2026年10月4日。