Baseten 旧镜像留下高权限凭据，删掉文件并不等于删掉秘密
Strix 披露的一起 Baseten 安全事件显示，研究团队在一个可公开拉取的旧容器镜像中发现仍然有效的 GitHub 凭据。按披露时间线，问题于 7 月报告并修复，9 月公开；它不是刚发生、仍未处理的入侵通报。
作者：韩启明｜OC 政策与安全编辑
Strix 披露的一起 Baseten 安全事件显示，研究团队在一个可公开拉取的旧容器镜像中发现仍然有效的 GitHub 凭据。按披露时间线，问题于 7 月报告并修复，9 月公开；它不是刚发生、仍未处理的入侵通报。
一句话结论：容器镜像的秘密可能留在构建历史里，修正 Dockerfile 也不会自动撤销已经泄露的权限。
风险不在于镜像能下载，而在于里面带着什么
公开容器镜像本身是一种正常分发方式。真正需要解释的是，公开内容是否包含内部代码、敏感配置或仍有权限的凭据。
Strix 表示，其 Agent 在约 25 分钟内发现了有效令牌，并通过只读方式核验了权限。这是安全产品供应商对自身调查过程的描述，不是独立的渗透测试效率排行榜。
比“25 分钟”更值得注意的是，旧产物和当前权限形成了连接：一个早已完成使命的构建步骤，仍然可能影响今天的系统。
删除文件，不会改写全部构建记录
镜像不仅有最终文件系统，也有层与配置元数据。构建时把秘密展开到命令里，可能让秘密进入历史记录；之后清理某个文件，并不能保证其他位置没有副本。
Docker 官方文档明确提醒，不应使用构建参数或环境变量传递构建秘密，推荐使用秘密挂载等专门机制。
但专门机制也不是护身符。消费秘密的命令如果又把它写进配置文件、日志或产物，依然会留下痕迹。安全检查需要跟着数据的实际流向走，而不是只确认采用了某个选项。
一张下载凭据，不该顺手拿到管理权限
按披露，令牌对部分内部仓库具有管理或推送权限。获取私有依赖通常只需要受限读取，而广泛写权限会把凭据泄露放大为供应链风险。
这里需要区分“存在可修改的权限”和“已经发生恶意修改”。研究者表示没有推送、改配置或克隆客户仓库；公开材料不能据此证明客户系统遭到实际篡改。
这种区分不会降低事件严重性。它让防御者更准确地评估暴露面，同时避免把潜在影响写成已经发生的损失。
把仓库关起来，还不是处理结束
披露时间线中，镜像项目先被设为私有，令牌随后完成轮换。这个顺序恰好说明两个控制点的区别：关闭入口阻止新的下载，撤销凭据才处理已取得副本的人。
如果只有前一项动作，已经流出的令牌仍可能在其他位置继续使用。反过来，只轮换令牌而不修构建过程，也可能在下一次构建时留下新的秘密。
完整处理因此需要同时覆盖访问配置、凭据生命周期和产物生成方式。三者互相补充，不能互相替代。
旧标签也属于正在承担风险的资产
团队容易把扫描资源集中到最新镜像，因为它最接近当前业务。但攻击者不必遵守公司的发布节奏，只要旧版本仍可取得，就仍可能提供有效线索。
可执行的治理思路是建立产物清单、标明暴露范围、设置合理保留策略，并让构建凭据具备最小权限与有效期。检查也应包括历史记录，而不只扫描最终目录。
AI 可以加快发现路径，但这起事件暴露的核心问题并不新奇：长期有效的高权限秘密，与长期可访问的旧产物相遇。防御措施需要先切断这条连接，而不是只购买一个更快的扫描器。
关键事实
调查与修复发生于 7 月，9 月公开；过程与修复结果来自 Strix 披露；有效权限不等于已发生恶意修改；公开入口关闭与凭据撤销是不同动作。
OC 判断
最值得借鉴的是产物、凭据和权限三张清单能否对上，而不是把一次厂商案例当成 Agent 无所不能的证明。
为什么重要
旧容器可能把历史构建失误带进当前权限体系。对开发团队和云供应商，秘密管理必须覆盖整个产物生命周期。
评论
围绕这篇文章补充信息、提出问题或分享观察。