如何防止个人或团队修改特定仓库的GitHub Actions工作流配置

• 现有GitHub仓库已配置路径为/.github/workflows/build.yml的GitHub Actions工作流，负责执行CI构建任务
• DevOps团队管控要求：禁止开发团队成员修改CI流水线配置，开发人员仅可在功能分支修改工作流文件之外的业务内容
• 核心目标：防止开发者篡改工作流配置，避免通过修改流水线绕过集成构建质量校验，同时在PR人工审核、PR自定义脚本校验两种方案外，寻找更稳定可靠的实现路径

你提到的两个方案都有明显漏洞：纯人工PR审核全靠审核人仔细核对改动，很容易漏过恶意修改；自己写脚本校验PR改动的方式，如果脚本本身跑在业务仓库的工作流里，开发者改流水线的时候直接把校验步骤删掉，等于完全没防住。
下面几个方案都是基于GitHub原生能力实现，不用额外搭服务，从系统层面卡控，基本没有被绕过的可能，可靠性比前两个方案高很多：

基础方案：CODEOWNERS + 分支保护（所有GitHub版本都能用，配置10分钟搞定） #

1. 在仓库根目录新建CODEOWNERS文件，加一行规则，指定工作流文件的专属审核方：

   # 改动CI工作流必须经过DevOps团队审批
   /.github/workflows/build.yml @devops-team
   

   这里把@devops-team替换成你们实际的DevOps团队GitHub组名就行。
2. 给主干分支（main/master这类生产分支）配分支保护规则，强制开这几个配置：
   • 禁止所有人直接向主干推代码，不管是开发还是管理员，所有变更必须走PR流程（管理员豁免可以按需开，一般建议关）
   • 开启「PR必须通过审核才能合并」，同时勾选「代码所有者审核为必填项」——只要PR里改了build.yml，系统会自动把DevOps团队设为必须审核的角色，没有DevOps成员审批，PR根本点不了合并，不会出现漏审
   • 把CI构建的执行结果设为必填状态检查，CI没跑过的PR一律不许合并

进阶方案：路径级权限限制（GitHub Enterprise可用，管控更严） #

如果你们用的是企业版GitHub，直接在分支保护规则里加受保护路径，把/.github/workflows/整个目录加进去，设置只有DevOps团队成员能改这个路径下的文件。其他开发提交的PR只要碰了这个目录的文件，系统直接拦截，连进审核流程的机会都没有。

最高强度方案：抽离可复用工作流（彻底堵死绕过路径） #

如果要做到哪怕业务仓库里的工作流文件被改了，开发也绕不过质量校验，就把CI核心逻辑从业务仓库完全挪走：

1. 单独建一个只有DevOps团队有修改权限的仓库，把原来build.yml里的构建、代码扫描、质量校验所有核心逻辑，全部做成GitHub可复用工作流
2. 业务仓库里的/.github/workflows/build.yml只留几行调用代码，引用管控仓库里的可复用工作流时，直接写死核心逻辑对应的commit SHA值，别用分支名、tag这类可以被篡改的引用
3. 给管控仓库配上最严的分支保护，只有DevOps能改核心CI逻辑。这种模式下，开发就算改了业务仓库里的工作流文件，也碰不到真正执行校验的逻辑，根本没机会绕过检查。

别把检测工作流改动的自定义脚本放在业务仓库的工作流里跑，这种属于自己监督自己，开发者改build.yml的时候顺手把校验步骤删了，管控直接失效。如果一定要做自动化校验，就把校验逻辑放到独立的管控仓库里，通过仓库的PR事件触发运行，不要依赖业务仓库里的工作流配置。

内容的提问来源于stack exchange，提问作者Srinivas Charan Mamidi