我们正准备将自身及客户的数据托付给贝斯滕（Baseten）用于推理服务，为安全起见，先运行自研的自主黑客代理斯特里克斯（Strix）扫描其安全性。约25分钟后，斯特里克斯获取到一个活跃的GitHub个人访问令牌，该令牌对贝斯滕内部仓库拥有仓库级管理员权限，可访问其主产品代码库、驱动集群的GitOps仓库及Homebrew tap等私有仓库。

我们正准备将自家和客戶的数据托付给 Baseten 做推理，为安全起见，先用 Strix 扫描他们。约 25 分钟后，Strix 拿到了一个对 Baseten 内部仓库有仓库级管理员权限的活跃 GitHub 令牌。

我们开发自主黑客代理 Strix，需要便宜快速的推理，因此考察估值 130 亿美元的 Baseten。作为安全公司，在交出数据前会先扫描第三方。我们将 Strix 指向 *.baseten.co，无凭证无源码运行。

Strix 返回活跃的 GitHub 个人访问令牌 basetenbot，该令牌对 Baseten 主产品仓库、驱动集群的 GitOps 仓库、Homebrew tap 有管理和推送权限，并对其他私有仓库（含按客户划分的仓库）有读写权限。镜像构建于 2023 年 3 月，2026 年 7 月发现时令牌仍有效。

先提一句，Baseten 安全团队确认问题严重，次日下午前锁定 registry 项目并轮换令牌，专业迅速。

Strix 是如何发现的

Strix 像正规渗透测试先侦察，枚举主机、查证书日志、绘制攻击面，找到 Harbor 注册表 gcp-us-east4-zlw.registry.baseten.co。

Harbor 存储容器镜像，其中一个项目公开。无需令牌，Strix 能列出仓库、获取匿名拉取令牌、下载镜像清单和 blob，包括 baseten/baseten-app 镜像。

Strix 拉取镜像查看内容。它思考：若项目本不应公开，关键要证明匿名拉取能拿到专有代码、内部二进制、硬编码凭证或主机名。先在 app 镜像发现一对 AWS 密钥，但调用 sts:GetCallerIdentity 返回 InvalidClientTokenId，密钥已死。

然后，一个真正有效的令牌

Strix 拉取层、运行 TruffleHog 并直接检查镜像配置，在 history[].createdby 中找到经典的 GitHub 令牌。该字段记录构建步骤，其中包含带有展开 GITHUBTOKEN 值的 RUN 命令。

Strix 用令牌向 GitHub 发只读 GET /user 请求，返回 200，账户名 basetenbot。

Docker 镜像除文件系统层外，还有含构建历史的配置，可随镜像下载。即便清理了凭据文件，若构建历史仍含令牌副本则无效。

此令牌三年多后仍有效。

basetenbot 能做什么？

活令牌本身有趣，但权限才关键。GitHub 返回 X-OAuth-Scopes: repo，账户属于 basetenlabs。

各仓库权限如下：

| 仓库 | 权限 | | --- | --- | | basetenlabs/b* | 管理员真，推送真 | | basetenlabs/f | 管理员真，推送真 | | basetenlabs/h | 管理员真，推送真 | | basetenlabs/r | 私有，读写 | | basetenlabs/b | 私有，读写 | | basetenlabs/t | 私有，读写 | | basetenlabs/b** | 私有，读写 |

公开可下载镜像中留下如此大权限令人震惊。b* 是产品主源码库，持令牌者可篡改别家依赖代码。f 是 GitOps 仓库，含集群期望状态，管理员权限可改生产基础设施。h 是 CLI 分发渠道，篡改可成供应链攻击。另有一个 f* 私有仓库，顶层 customers/ 目录按客户名分子目录。

我们到此足以报告且确信非误报，未克隆客户仓库、未推送、未改配置，立即停止并写披露邮件。

令牌如何到那里的

构建历史时间戳显示含令牌步骤运行于 2023 年 3 月 3 日，旧构建凭据至 2026 年 7 月仍具全部权限。

常见错误：构建需从 GitHub 取私有依赖，有人将令牌作为构建参数传入，类似：

1 ARG GITHUBTOKEN 2 RUN GITHUBTOKEN=${GITHUBTOKEN} bash -c '\ 3 if [[ "${GITHUBTOKEN}" != "" ]]; then \ 4 git config --global --add \ 5 url."https://${GITHUB_TOKEN}@github.com/".insteadOf "git@github.com:"; \ 6 fi'

Docker 会将构建参数记入镜像元数据历史，本例记了真实令牌值。Docker 明确警告过。此外 git config --global 将认证 URL 写入 Git 配置，即便改令牌传入方式也需避免存入镜像。

修复用 BuildKit secret mount 和临时认证，不持久化凭据，并检查镜像层和历史，撤销旧令牌。

Strix 自主做了什么

Baseten 安全团队响应快，且已用 AI 安全工具，但 2023 年构建的令牌仍有管理员权限。容易忽视旧容器镜像。即便扫文件也要查构建历史。

Strix 自主跟进：发现注册表、验证拉取、测死凭据、在历史中找另一凭据并查权限，全程约 25 分钟，我们未提示 Harbor 或令牌。

这正是我们建 Strix 的原因：AI 攻击渐可怕，唯有持续自黑找问题。

披露

Baseten 处理得当：7 月 13 日 23:10 报告令牌等；14 日晨设为私有；14 日 16:34 Anton 确认严重并轮换令牌，要求删镜像；17:05 我们确认删除并发另两低危；17 日闭环；9 月告知公开并发草稿。他们送了 T 恤卫衣致谢。

去查你的旧镜像

若运行容器并用 GitHub，值得自查：

1. 查看无需登录可拉取什么，含旧标签和遗忘项目。
2. 用 docker history --no-trunc 读构建历史，或查 config blob 的 history[].created_by，也查层。
3. 将密钥移出构建参数，用 secret mount，确保消费命令不写回镜像。
4. 检查构建令牌实际权限，按需最小授权并设过期。

用 Strix 之类扫自己系统。整个扫描始于想用推理服务商，给个域名就返严重漏洞。AI 攻击者能走相同路径，若代理 25 分钟能在旧镜像找到管理员令牌，你要让自己的先找到。

讨论的火药味集中在两个方向：几乎所有人都认定 Baseten 的凭据管理已经失控到不可接受，但真正吵起来的是 Strix 主动放出 agent 扫 *.baseten.co 到底算不算越界。主流情绪是既服气这次发现和披露的干净利落，又对"安全公司派 AI 去打别人"的法律定性心里打鼓，另有若干人顺势把矛头指向 GitOps、长期 token 和 GitHub 托管这套行业惯例。

认为未经授权扫描第三方踩了法律红线

• 有人拿入室作类比，质疑即便没有窃取意图，主动破开别人系统的门也可能构成违法；也有评论指出一家懂法的安全公司主动放 AI agent 去打目标，等于把案子直接递到律师手上。（较多人） > 我不可能因为没打算偷东西，就可以撬开邻居家的锁进去看看。（@codemog）
• 还有人对"没被曝光的 agent 驱动型攻击"表示不安，担心类似的自动扫描正在被恶意方批量使用而我们听不到任何消息。（少数人）

认为这是教科书式的负责任披露，顺便给 Strix 做了最好的广告

• 有人梳理了完整时间线：7 月 13 日报漏洞，次日 Baseten 将项目转私有并轮换 token，17 日关闭剩余问题，9 月双方沟通公开披露，事后 Baseten 还寄了周边致谢。（较多人）
• 有人直言这是任何安全产品都梦寐以求的营销素材，看完就准备把它加进自己的技术栈；也有正在评估 Baseten 作为推理供应商的人表示，快速打补丁值得肯定，但这件事已经进入决策考量。（较多人） > 没有比这更好的故事来推销自家安全产品了。（@aatd86）

认为真正的锅在 Baseten 的凭据与权限管理

• 首页挂着 SOC 2 Type II 与 HIPAA 合规标识，客户覆盖医疗、法务等高度敏感行业，但那个握有主干产品仓库、集群 GitOps 仓库、Homebrew tap 以及按客户划分的私有仓库读写权限的管理员 token，从 2023 年的镜像一直活到被发现。（较多人） > 构建日期是 2023 年 3 月，到 2026 年 7 月被发现时它仍然有效。（@thrownaway22）
• 有评论认为这是最小权限和防御纵深完全缺位的必然结果，属于本可轻易避免的问题，并顺带指出近期多起入侵都绕不开 GitHub。（较多人）
• 也存在替初创公司说话的声音：大家都在和时间赛跑，为了活下去砍掉一些安全流程几乎是必然。（少数人）

认为客户反过来审查供应商这件事本身就颠倒了

• 一家初创公司在签约前先验证服务商够不够安全，而这家服务商早已被众多大厂把客户数据交托过去，顺序完全反了；同时这个漏洞不是孤立偶发，而是安全实践成熟度的症状。（较多人） > 不应该是反过来吗？（@sandeepkd）

有价值的补充

• Docker 构建参数会留下构建元数据，加 --provenance=false 可以去掉；更稳妥的做法是用 build secret，把敏感值限制在 Dockerfile 的特定作用域内，而元数据本身对排查镜像仍然有用。（@brewmarche）
• 只要某个子域名的单主机证书进了 CT 日志就等于暴露，在 AWS 上应当用通配符证书加 ALB 终止 TLS；公开与私有的 Git、Docker、npm 仓库必须拆到不同基础设施，私有部分只从内网可达，否则一个 GitLab RCE 就能同时端掉两者。（@mschuster91）
• 同一条还反对把 terraform apply 塞进 Git 流水线：只读 token 做 lint 和 plan 可以接受，apply 应由管理员在可控机器上手动执行，否则一个 CI 漏洞配上全权云 token 就直接失守。
• 把专有代码、CI/CD 和 GitOps 放在公有云上越来越像露天堆放硝酸铵，只有本身围绕开源的业务才适合在 GitHub 上放镜像。（@stopthe）
• 有人主张取消一切长期凭据，先做到月度轮换，再往小时级推进。（@throwitaway222）
• Strix 一方留下一个开放问题：这件事该提炼出什么样的默认安全边界，供所有"凭感觉糊出来"的内部 agent 遵循。（@swyx）

玩笑与情绪

• 有人感叹这就叫进入 AI 经济了，只关心在把积蓄砸进 SPY 之前股价到底会涨还是会跌。（@vatsachak）
• 也有人把这种"接口是个 Docker 容器的 Markdown 即服务"式设计，看作软件整体走向的缩影，觉得沮丧。（@athrowaway3z）