Harden-Runner CI/CD 安全代理

解决什么问题

GitHub Actions 的 runner 默认在宿主机或临时虚拟机里执行第三方 action 和 run 脚本，工作流配置里的一句 runs-on: ubuntu-latest 并不代表运行时有边界。当依赖被投毒（如 tj-actions、Codecov 这类供应链事件）时，恶意进程会在构建阶段直接落到 runner 上：读取环境变量里的 token、回传产物、篡改依赖缓存。传统做法是给 workflow 加权限收敛和 linter，但这些规则只能约束“声明了什么”，管不到“进程实际做了什么”。

技能如何工作

Harden-Runner 的思路接近 EDR：把监控下沉到 runner 运行时，对真实行为做观察，而不是解析 YAML 配置。核心能力集中在三处：

• 网络出口监控：记录进程发起的出站连接，便于定位意外的对外调用（上游文档就记录过一次异常出站调用，最终推动了 Docker 文档更新）。
• 文件完整性：跟踪构建过程中对文件系统的改动，用于发现依赖目录、构建产物被非预期改写的情况。
• 进程活动：观察 runner 上实际拉起的进程，把命令行、父子关系纳入视野。

接入路径相对直接：按官方文档在 workflow 中启用该 agent，它会随 job 一起运行并持续采集上述三类信号，再结合预置策略对高风险行为告警。对供应链攻击的典型判定逻辑，是把“运行器本不该出现的出站、写入、进程组合”暴露出来，而不是等到密钥泄露后才回溯。

适用边界与注意点

• 它解决的是运行时可见性问题，不替代依赖锁定、SBOM、workflow 权限最小化等上游防护；供应链安全需要分层。
• 告警质量依赖基线。大型仓库的构建普遍需要访问 registry、包管理源等，初期可能产生噪声，需要结合环境做策略校准。
• 上游文档明确列出了 requirements 与 caveats，接入前建议先在非关键流水线验证，确认对现有构建行为没有干扰。
• 采集到的网络、文件与进程数据属于敏感观测信息，使用前应评估其留存与访问范围。