OpenCode公布了一起安全事件，受影响范围是Console用户的1.4%。这个数字有个前提条件：只覆盖那些绑定了外部服务商的用户子集。公司称已向这批用户发送邮件，未收到邮件的人不在影响范围内，事件仍在处理中。
1.4%这个比例，分母必须跟着一起说。分母是Console用户，公告没有给出Console用户的总量，所以算不出绝对受害人数。同样不能把这个比例套到所有OpenCode安装量、月活用户或GitHub关注者身上——两个不相干的数字相乘，能做出很唬人的图，但结论是错的。
公告提到团队正与Anthropic、OpenAI和Google合作处置，细节因事件仍在进行中暂不披露。这些都是响应层面的表述。几个常规问题仍然悬着：访问是怎么拿到的、具体哪个凭证处理环节出了问题、发生了多少未授权活动、后续改什么来防止重演。
关于额度异常或意外用量的个人反馈值得跟进核查，但目前没有独立验证，也不构成损失总额，公告里同样没有可核实的赔付承诺。一张账单截图，在说清楚是什么导致了变化之前，还不足以成为事件级别的结论。
先画一张凭证地图
OpenCode的产品页把它描述为面向终端、编辑器和桌面的开源编码代理。Console的模型文档则描述了一个可选的服务商通道，可以配合OpenCode或其他编码代理使用。也就是说，一个人完全可以用OpenCode搭配另一套服务商方案。本地代理的名字，无法证明这个人是否用了受影响的那套托管服务。
Console服务商文档给出一条具体的架构事实：Console存储已连接服务商的凭证，并通过自己的网关转发请求。工作区成员可以使用模型，但看不到上游服务商的密钥；所有者和管理员通过Providers标签页管理这些连接。
这套安排的管理好处很直接：团队共享模型访问，不用把上游密钥复制给每个成员。代价同样直接：网关对一把能打开外部服务的凭证负有责任。文档里的便利和文档里的信任边界，是同一个设计的两面。
做凭证盘点时，可以把几件事分开列：
- 凭证实际存放在哪个组件里
- 这把凭证能触达哪个上游账户
- 谁负责吊销和更换
- 哪些集成在更换后需要同步更新
这是一份盘点模板，不是对攻击路径的还原。照着方框画一条攻击者移动路线，等于暗示了公告并未提供的信息。真正的失效点可能落在服务的其他环节，最终的技术报告需要对此作出解释。
把比例限定得窄，也不等于影响微不足道。一个子集里可能就有暴露程度很严重的人。范围清晰，能帮这批人找对应对动作，也能帮其他人避免把一个不相干的组件当成已确认的受害方。
凭证可能暴露时查什么
先看官方通知，再看自己的账户配置。确认外部服务商是否通过Console连接过，核对公司声称已发出的那封邮件。账户情况仍有疑问，走官方支持渠道，就具体配置提问，而不是从别人的回复帖里自行诊断。
然后查服务商侧的活动记录。在条件允许且不影响控制可疑使用的前提下，改动凭证安排之前先保留相关时间戳和记录。确认有可疑活动，就到签发该凭证的服务商那里吊销它。受影响的集成要有意识地替换，别留一个静默失败的工具在后台跑。
这些是通用的应急习惯。OpenCode的公告没有发布完整的客户处置清单，公司和相关服务商给出的更新、账户级指令应当优先遵循。事件仍在进行中，正式发布前值得再核对一次公告。
面向未来的集成，记录三件事：凭证放在哪、它通向哪个上游账户、谁负责吊销。服务商支持的话，收窄它的权限和消费额度。定期查看活动，维护一份更换后需要更新的依赖清单。具体控制手段取决于服务商和账户类型，一句“全部轮换”的口号替代不了这份盘点。
服务的访问控制和代理的工作权限也该分开看。代码审查钩子、终端提示、模型给出的自信回答，提供的是另一种性质的保证，它们不能证明一个托管凭证存储是安全的。
“蒸馏攻击”说明了什么
Anthropic的背景解释把蒸馏定义为：用更强模型的输出训练一个能力较弱的模型。这项技术也有正当用途，服务商可以把自己的模型蒸馏成更小的版本；未授权提取则是另一回事。
OpenCode把这起事件与大规模蒸馏攻击关联起来。合理的读法是：这描述的是被指控的行为目的，访问机制仍然空白。这几个字没有指认攻击者，没有解释凭证是怎么被处理的，也没有量化客户侧发生了什么。
Anthropic那篇2月文章讨论的是另外几起案例，其中点名的机构和账户总数只能挂在那几起案例上，不能用来给这次OpenCode事件做归因。一个故事可以有说得通的动机，同时缺一个公开的技术原因，这两项在报道里应当分开记。
后续报告应当帮客户回答：他们实际使用的系统里，什么被改变了。在那之前，一张精密的攻击示意图，主要展示的是画图的人连箭头连得有多顺。
眼下能落地的动作只有一个方向：搞清楚到底是哪个服务持有你的服务商访问权限。这条信息在头条滚下首页之后，依然有用。
热门跟贴