Grafana Labs 源码被盗后拒付赎金：别把供应链风险误读成客户数据泄露

攻击者拿到的不是客户数据库，而是 Grafana Labs 的 GitLab 开发环境访问权限。

这个区别很关键。

Grafana Labs 是开源可视化工具 Grafana 的开发方。Grafana 常被企业用来展示监控指标、日志和业务看板。公司确认，攻击者使用被盗 token 进入其 GitLab 环境，获取了源码仓库，并以公开代码相威胁要求付款。Grafana Labs 表示不会支付赎金。

我更在意的不是“开源公司的代码被看见”这句话，而是开发链路被打开过。源码被盗不等于客户数据泄露，但它足以让企业重新评估供应链风险。

这次被打开的是开发环境，不是客户数据系统

Grafana Labs 披露的信息里，攻击入口是一个被盗 token。这个 token 可访问公司用于代码开发的 GitLab 环境。

公司称，该 token 不能访问客户记录或财务数据。公司还表示，相关 token 已失效，并已增加额外安全措施，降低类似事件再次发生的概率。

把目前已确认的信息拆开看，边界会清楚很多：

这也是这起事件最容易被误读的地方。

说“源码被盗”，不等于说“客户数据泄露”。目前没有证据支持后者。

但反过来，说 Grafana 是开源项目，也不能推出“这事完全没风险”。开源代码可以公开下载，企业内部开发仓库却可能包含更多东西。

比如企业版相关代码、内部构建脚本、CI/CD 配置、测试凭据、未发布补丁，甚至安全修复计划。原始披露尚未确认攻击者是否拿到了这些内容。

这才是风险边界。

企业客户和开发者该查什么

对企业安全负责人来说，最现实的动作不是立刻下结论，也不是马上迁移。迁移有成本，替换监控体系更不是一两天能完成的事。

更合理的做法，是把供应商问清楚。

如果使用 Grafana Cloud 或企业版，应优先要求 Grafana Labs 说明几件事：受影响仓库范围、是否涉及专有代码、是否发现凭证或内部配置暴露、构建链路是否完成完整性检查、是否需要客户侧轮换任何凭证。

如果是自托管 Grafana，重点略有不同。自托管用户要盯后续安全公告、补丁版本和是否存在可被下游利用的漏洞线索。不要只盯着“有没有付赎金”。

对开源软件使用者和开发者，这件事也有一个直接提醒：token 不是小事。

很多入侵不需要高深的漏洞利用。一个长期有效、权限过宽、监控不足的访问令牌，就可能成为进入研发系统的钥匙。

团队可以马上复查三类问题：

• 长期 token 是否仍在使用，能不能缩短有效期；
• token 权限是否过宽，是否遵循最小权限；
• GitLab、CI/CD、制品库和云资源之间，是否存在一把钥匙开多扇门的情况。

采购侧也会受到影响。

如果企业正在评估 Grafana Cloud 或相关商业服务，短期内更可能延后安全评审，而不是直接否决。评审重点会从功能和价格，转向事故披露质量、权限隔离能力和供应链审计能力。

这不是苛刻。开发环境一旦被碰过，信任就要靠证据补回来。

拒付有道理，但拒付不是结案

Grafana Labs 引用 FBI 的长期建议，表示不会向攻击者付款。这个选择有现实理由。

付款不能保证攻击者删除数据，也不能保证不再公开或转卖。更麻烦的是，付款还可能鼓励下一轮勒索。

但拒付不是安全终点。它只是处理勒索时的一种立场。

对比 Instructure 的案例，压力结构会更清楚。TechCrunch 报道称，教育科技公司 Instructure 在网络两次遭入侵、员工和学生相关数据遭威胁后，与攻击者达成付款协议。Grafana Labs 这次面对的是源码勒索，并且公司称客户记录和财务数据未受影响。

两家公司面对的筹码不同，选择也就不同：

所以，Grafana Labs 拒付值得肯定，但不能因此把事件轻轻放下。

接下来真正要看的，是调查能不能回答几个硬问题：仓库里有没有凭证、密钥或内部配置；有没有专有代码被获取；有没有未披露漏洞或修复计划外泄；攻击者是否具备利用这些信息攻击下游用户的能力。

目前这些问题还看不清。

这起事件给开源商业公司的提醒很直白：代码可以开放，开发系统不能松。开源项目赢得信任，靠的不只是透明代码，也靠凭证管理、权限隔离、访问审计和事故披露。

企业用户也该把这套问题写进采购和续约流程。星标、功能、生态都重要，但供应商怎么守住开发链路，同样重要。