CrowdSec 确认代码泄露，公开引擎与私有控制台要分开看
据 CrowdSec 官方声明，公司于 9 月 16 日获知并确认了一起发生在 2026 年 5 月的源码泄露。涉及的是私有代码部分，不能与原本就公开的开源安全引擎混为一谈。
作者：韩启明｜OC 政策与安全编辑
据 CrowdSec 官方声明，公司于 9 月 16 日获知并确认了一起发生在 2026 年 5 月的源码泄露。涉及的是私有代码部分，不能与原本就公开的开源安全引擎混为一谈。
一句话结论：源码泄露已经确认，客户数据泄露并未因此被证实；调查重点应落在私有代码访问权限和泄露材料的实际内容上。
安全事件里的一个大数字，很容易遮住真正需要解释的边界。这次外界提到约 300 个仓库，CrowdSec 说明其中包括 130 多个本来公开的仓库。仓库数量还受到代码如何拆分的影响，并不能直接换算成泄露规模或损害程度。
公司列出的私有部分包括 SaaS 控制台、部分云端例程、连接器与自动化代码。公开安全引擎不在这次私有源码泄露范围内。这个区分既不是说事件无关紧要，也不是说使用其开源引擎的人已经遭到入侵。
已确认的事，和正在调查的事
CrowdSec 表示，没有客户数据及登录凭据等内容泄露，检查中也尚未发现可用于横向移动的敏感凭据。这是公司的调查结论，当前报道应保留归属和时间边界，而不是把它写成独立审计已经给出的永久保证。
关于路径，公司认为此前的 TanStack 供应链事件“很可能”是入口：相关组件可能提取了具备私有代码读取权限的 CI/CD API 密钥。声明尚未把整条路径描述为最终定论，因此报道也不应替调查提前结案。
读代码的权限，也是一项重要资产
这件事提醒团队，CI 里不只有发布生产环境的密钥。能读取私有仓库的凭据，同样可能暴露内部实现、接口约定和部署相关逻辑。即便一个令牌不能直接登录生产系统，也不意味着它没有价值。
从防护角度说，需要把“构建任务需要读哪些仓库”说清楚。若为了省事给一个组件覆盖整个组织的读取权限，某个依赖出问题时，影响范围就可能超出单个项目。这是权限设计的普遍风险，并非对本次泄露路径的额外确认。
轮换凭据可以阻断旧凭据继续使用，却无法收回已经复制出去的代码。后续检查还需要关注历史代码是否含有仍有效的敏感配置，以及是否存在应该单独修复的实现问题。不能只看当前主分支已变化，就推断旧副本没有价值。
四个月过去，不等于影响自动消失
CrowdSec 说大部分相关代码在过去数月已有较大变化，并已轮换所需令牌与凭据。变化能够影响泄露材料的可用性，但没有逐项核对，就不能推出“代码过时所以没有风险”。
同样，外界也不应仅凭源码曝光就宣称客户系统失守。判断安全事件需要沿着证据走：到底复制了什么，哪些权限曾被使用，是否出现异常操作，还有哪些结论正在等待日志或其他证据支持。把这些问题展开，比围绕仓库总数制造惊慌更有用。
关键事实
- 确认时间：公司 9 月 16 日获知并确认；事件发生时间据称为 2026 年 5 月。
- 涉及范围：私有 SaaS 及相关代码；公开引擎本就公开。
- 调查状态：供应链入口属于高可能性判断，尚非完整定案。
- 客户影响：公司称未泄露客户数据，应明确这是公司截至声明时的说法。
OC 判断
风险要拆开看。OC 不会把公司对业务影响的乐观解释当作技术证明，也不会把私有源码泄露升级成尚无证据的客户入侵。此事最值得借鉴的是构建链权限盘点：谁能读代码、凭据持续多久、异常访问能否被发现。
为什么重要
- 对维护者：开源组件公开与私有基础设施泄露是两类问题。
- 对安全团队：只盘点生产密钥，会遗漏代码读取权限的风险。
- 对客户：关注后续正式调查与明确行动要求，比下载流传的泄露材料更有意义。
评论
围绕这篇文章补充信息、提出问题或分享观察。