你以为 CI/CD 安全只是管好自己的 pipeline，今天 autonomous agent 用 25 分钟把这个认知扒了个干净

有一家安全公司，准备把自己的推理任务跑在 Baseten 上。130 亿美元估值、一堆企业级客户，在 AI infra 领域是响当当的名字。在把数据交出去之前，按惯例扫一圈供应商——结果点开了一个 autonomous hacking agent，25 分钟后，它拿到了一把活着的 GitHub admin token，带有 Baseten 主要产品仓库的写权限。

这不是 APT 攻击，也不是国家级黑客。这是一个 autonomous pentesting agent 对着 Baseten 的公开基础设施跑了 25 分钟的正常操作。

25 分钟，黑客拿到了什么

Baseten 被一家安全公司拿来做投喂前的测试。这家公司做了个 autonomous hacking agent 叫 Strix，在安全圈子里是开源项目，Apache-2.0 协议，54K 星，背后公司提供商业平台。客户包括 AWS、PayPal、Uber、Cisco、ByteDance 的安全团队。

他们在 Strix 里开了个 target：*.baseten.co，不需要任何凭证，不需要 access token，纯黑盒。

25 分钟后，Strix 回来了一把活的 GitHub Personal Access Token（PAT），用户名 basetenbot，具备仓库级别的 admin 权限。Token 日期戳是 2023 年 3 月，到 2026 年 7 月被发现时仍然有效——三年四个月的暴露窗口。

这把 token 有什么权限：

• basetenlabs/baseten：主产品仓库，admin + push
• basetenlabs/flux-cd：GitOps 仓库，控制着线上集群的实际部署状态，admin + push
• basetenlabs/homebrew-tap：Homebrew 分发包，push
• 若干客户私有仓库：read/write

basetenbot 不是 scoped read-only key，是仓库级 admin + push。token 拿着写权限，能改代码，能 push commit，能触发 GitOps 自动部署——相当于把代码和生产的钥匙同时交了出去。

根因：Docker ARG 不是 build-time 变量

Token 怎么进镜像的？

Build-time 往 Docker 镜像里塞秘密是个老坑。标准操作是在 Dockerfile 里写：

ARG GITHUB_TOKEN
RUN git clone https://${GITHUB_TOKEN}@github.com/basetenlabs/baseten.git

这个 ARG 写进了镜像 config.json，不是运行时变量，是 image metadata，会被 docker history 和 docker inspect 全部暴露。Strix 扫镜像用的工具叫 TruffleHog，就是专门干这个的——从 image config 里把历史层和元数据扒出来，找明文 secret。

正确做法是用 Docker build secrets，secret 不会进镜像层：

RUN –mount=type=secret,id=github_token
GIT_TOKEN=$(cat /run/secrets/github_token) &&
git clone https://${GIT_TOKEN}@github.com/basetenlabs/baseten.git

或者 CI 层面直接用 OIDC short-lived token，不要 PAT，用 GitHub App 安装 token，每小时自动过期，不存在 long-lived secret 可以泄露。

三年四个月，没人发现

比 token 泄露本身更值得问的问题是：三年四个月，多少次安全评估、多少次供应商审计、多少次信任审查，没人扫过这个镜像？

GenZTech 在原披露文章里写了句大实话：token 泄露每天都在发生，真正有意思的是——一家处理企业客户推理任务的公司，一次 2023 年 3 月的构建失误，过了三年四个月才被一个 autonomous agent 自己找上门来发现，而不是被内部例行审计发现。

大多数成长期 infra startup 的安全状态就是这样：出了事，要么自己发现，要么靠研究者博客披露，中间没有第三条路。

CI/CD 的攻击面比你想象的大

这件事值得所有团队警醒：CI/CD 系统天然持有大量高价值凭证——云厂商 deployment token、npm 发布 token、代码签名 key、production 数据库连接信息。攻击者知道这点，所以 CI/CD 一直是供应链攻击的首选跳板。

具体到这个案例：Baseten 是 AI inference 平台，客户把自己的模型跑在 Baseten 的 infra 上。攻击者如果拿到了那把 token，进了 GitOps 仓库，就能改代码、触发部署——相当于把客户模型的运行环境和数据处理管道全部捏在手里。

这不是数据泄露，这是供应链投毒。

怎么检查自己的镜像

如果你想自检：

第一步：用 Trivy 或者 Docker Scout 扫自己的镜像，看有没有 secrets 暴露。

docker run –rm -v /var/run/docker.sock:/var/run/docker.sock aquasec/trivy image –security-checks secret 你的镜像名

第二步：检查 CI 里有没有用 long-lived PAT，尽量切到 GitHub App 安装 token 或者 OIDC short-lived token。

第三步：确认 container registry 项目设置，Harbor 或者 GHCR 的项目级别权限有没有设 public 匿名可拉。

第四步：定期用 autonomous security tool 扫自己的外部暴露面，别等攻击者来帮你扫。

真正的教训

Baseten 事后处理很专业：确认为 critical、第二天上午旋转 token、锁项目。这值得肯定。但三年零四个月的窗口期，才是整个行业真正要回答的问题。

autonomous agent 用 25 分钟完成的事，任何人都能用开源工具复制。你的 CI/CD 管道有没有被人从外侧扫过？