依赖私有SSH密钥的第三方GitHub Actions是否真的安全？

• 你对GitHub官方运行环境的基础隔离逻辑的认知是正确的：官方托管的运行器会为每个工作流Job启动独立隔离的虚拟机实例，执行完成后整个实例会被彻底销毁；SSH密钥作为加密的仓库/组织Secret注入流程后，默认会被做脱敏处理，不会明文出现在运行日志、工作流产物中，不会因为平台本身的运行机制出现无意义的泄露。
• 但你认为“这类第三方Action的唯一风险是内置恶意代码，和所有处理私有数据的第三方软件风险一致”的判断存在一定偏差：
  • 这类基于自定义Docker容器的第三方Action，和直接拉取源码执行的Action有本质区别：当流程运行到这类Action的步骤时，实际运行环境完全是由Action维护方提供的镜像，你的SSH密钥被注入到这个容器后，容器对密钥拥有完全不受限的读取权限——哪怕Action本身没有恶意代码，也可能因为镜像供应链污染（比如镜像仓库被入侵、构建依赖被投毒）出现密钥被悄悄外发的问题。
  • 普通用户很难对这类容器做完整性校验：你能看到的公开源码通常只是构建镜像的代码，最终实际拉取到运行器里的镜像内容，是否和公开源码完全对应、没有被植入额外逻辑，绝大多数使用者根本没有能力核实。
• 行业内反感这类自托管Docker Action的核心原因，不是“把SSH密钥传给GitHub Actions本身就不安全”：
  • 只要你遵循最小权限原则，给部署流程单独生成仅能对目标服务器做文件上传操作的专用SSH密钥，不使用个人高权限的SSH密钥，同时将第三方Action固定到经过核对的具体版本commit哈希、不盲目跟随浮动的最新版本，这类Action的使用风险完全可以被控制在可接受范围内，和使用其他开源第三方组件的风险量级没有本质差异。
  • 真正的风险来源于密钥权限过大、Action版本不受控、对第三方提供的容器内容完全没有校验，导致一旦出现供应链问题就会造成高权限密钥泄露。

内容的提问来源于stack exchange，提问作者floatingpurr