GitHub公开仓库仅在受保护分支触发Push时用Self-hosted Runner是否安全？

背景 #

我正尝试配置Self-hosted Runner，使其在每次提交到master分支时构建并部署软件，但发现GitHub公开仓库使用Self-hosted Runner存在安全风险。

GitHub官方文档相关说明：

Self-hosted runner 安全
我们建议仅在私有仓库中使用Self-hosted Runner。因为公开仓库的fork版本可通过创建Pull Request（PR），在工作流中执行危险代码，进而在Self-hosted Runner机器上运行。
GitHub-hosted runners不存在此问题，因为每个GitHub-hosted runner都是全新的隔离虚拟机，任务结束后即被销毁。
在Self-hosted Runner上运行不可信工作流会给机器和网络环境带来严重安全风险，尤其是当机器在任务间保留环境时，风险包括：恶意程序运行、逃逸Runner沙箱、暴露网络环境访问权限、留存危险数据。

风险利用方式补充
GitHub-hosted runners在临时干净的隔离虚拟机中执行代码，无法被持久化攻陷；而Self-hosted Runner无此类保障，可能被工作流中的不可信代码持久化攻陷。
因此，GitHub公开仓库几乎不应使用Self-hosted Runner，因为任何人都可提交PR并攻陷环境；私有仓库也需谨慎，有读取权限的用户可fork仓库提交PR，进而获取密钥、GITHUB_TOKEN等。

原本我以为风险仅来自组织内共享Runner的恶意协作者，但文档指出公开仓库可接收任何人的PR并触发Runner任务。

我的组织计划在公开仓库使用Self-hosted Runner，并设置以下限制：

• 仅添加职场可信用户至组织；
• 仅在Push事件触发任务；
• 仅在master分支触发任务；
• master分支设为保护分支，仅我和少数管理员可写入；
• 无第三方自动合并fork仓库PR的机制。

但文档未提及分支保护和触发限制的影响，故提出以下问题：

1. 此配置下公开仓库使用Self-hosted Runner仍不安全吗？
2. 非组织外部用户能否利用该配置在Self-hosted Runner上运行未授权代码？
3. 外部恶意用户如何通过fork仓库并提交PR来利用该仓库？

解答 #

1. 此配置下的安全性判断 #

按你设定的严格规则，风险已经大幅降低，但并非绝对无风险。核心逻辑是：你的Runner仅响应master分支的Push事件，而master是保护分支，只有少数可信管理员拥有写入权限。只要管理员本身可信，且在合并外部PR时严格审核，未将恶意代码引入master，那么Self-hosted Runner执行的所有代码都是经过可信人员把关的，不会出现不可信代码被执行的情况。

但需要警惕两个潜在风险：一是管理员若疏忽大意，将包含恶意构建脚本或工作流修改的外部PR合并到master，推送后会直接触发Runner执行恶意代码；二是若管理员账号被盗，攻击者可利用权限直接向master推送恶意代码，触发Runner任务。

2. 外部用户能否运行未授权代码？ #

在当前配置下，外部用户无法直接在你的Self-hosted Runner上运行未授权代码。因为你的工作流仅触发master分支的Push事件，外部用户没有该分支的写入权限，无法主动触发该事件。同时你未启用自动合并外部PR的机制，外部PR不会自动进入master分支，也就无法触发Runner任务。除非管理员主动合并包含恶意代码的外部PR，否则外部用户无法触及你的Runner。

3. 外部恶意用户的潜在利用路径 #

在你的限制下，外部用户无法直接触发Runner，但可能通过以下诱导性手段尝试利用：

• 提交恶意PR：在自己的fork仓库中植入恶意构建脚本、修改工作流配置（比如新增额外触发条件），然后提交PR并通过话术诱导管理员合并。一旦PR被合并到master，Push事件触发后，Self-hosted Runner就会执行这些恶意代码。
• 社会工程攻击：针对组织内管理员发起钓鱼攻击，获取管理员账号权限，进而向master分支推送恶意代码触发Runner。
• 历史配置漏洞：如果仓库之前存在允许外部PR触发Runner的工作流配置，可能被恶意利用，但你当前的配置已规避了这类风险。

内容的提问来源于stack exchange，提问作者Aleix Mariné