Baseten 安全漏洞暴露管理员令牌，挑战 Neocloud 信任
在 Strix 仅用 25 分钟发现一个具有管理员权限、仍处于有效状态的 GitHub 令牌后，Baseten 修复了一项严重安全漏洞。这项 Baseten 安全漏洞始于一个可公开访问的容器注册表，最终指向支撑其 AI 推理平台的代码仓库。
这一发现并非来自计划中的审计或已报告的入侵事件。据 Strix 称，当时该公司正将 Baseten 评估为潜在的推理服务提供商，尚未决定将数据、模型或代码托付给对方。其自主安全代理仅获得了一个 Baseten 域名模式。
这使该事件比一般的凭证泄露更具影响力。一家企业买方在供应商筛选过程中发现了它，而据报道，该令牌自 2023 年 3 月构建镜像以来一直保持有效。Baseten 在收到通知后迅速采取行动，但这次暴露对围绕专业 AI 云服务的安全承诺提出了挑战。
Baseten 安全漏洞始于公共注册表
一个可匿名下载的容器镜像，打通了从 Baseten 公共攻击面到其高权限内部开发系统的路径。
Strix 通过梳理与 Baseten 相关的主机开始审查。该代理检查了证书记录、枚举子域名，并识别出一个 Harbor 注册表。Harbor 是一个用于存储和分发容器镜像及相关软件制品的系统。
据报道，该注册表中的一个项目允许无需身份验证即可访问。访客可以列出代码仓库、请求匿名拉取令牌，并下载镜像清单与数据层。这些能力使其能够访问名为 baseten/baseten-app 的镜像。
公共容器镜像本身并不必然构成漏洞。企业会有意发布镜像，供客户、集成方案和开源项目使用。因此，Strix 继续测试，以确定这些可访问的制品是否包含敏感材料。
该代理首先在镜像中检测到两组 AWS 凭证。一次只读身份请求返回了无效令牌响应，表明这些凭证已无法使用。这一结果降低了它们的即时重要性，但并未终止检查。
随后，Strix 扫描了镜像层并检查其配置元数据。该代理在 history[].created_by 中发现了一个 GitHub 个人访问令牌；该字段记录镜像构建步骤的创建方式。
该令牌显然被展开并写入了一条记录在案的 RUN 命令。即使后续容器未将密钥作为普通文件暴露，构建历史仍可能保留其值。
Strix 使用一项只读 GitHub 请求测试了该凭证。根据该公司详细的披露时间线，GitHub 返回成功响应，将该账户识别为 basetenbot。
据报道，该账户属于 Baseten 的 GitHub 组织。随后，代码仓库权限检查显示，它对多个内部代码仓库拥有管理员和推送权限。Strix 表示，其中包括 Baseten 的核心产品代码仓库、用于驱动集群的 GitOps 代码仓库，以及其 Homebrew 分发代码仓库。
GitOps 是一种运行模式，即由版本控制文件定义已部署的基础设施。因此，对 GitOps 代码仓库的访问所带来的影响，可能超出一般源代码可见性。一项恶意变更可能影响生产系统的配置或更新方式。
据报道，其他私有代码仓库也允许读取和写入访问。Strix 表示，其中一些与特定客户相关，但它没有下载其内容。该公司还表示，未推送代码、修改设置或克隆这些代码仓库。
这些限制很重要。现有证据支持该令牌拥有广泛权限这一说法，但并不能证明攻击者此前发现过该镜像、使用过该令牌、访问过客户信息，或更改过 Baseten 的系统。
这一区分将暴露与已确认的入侵分隔开来。一项凭证可能造成严重安全风险，但并不意味着已有证据表明有人利用了它。公开报道应保留这种差异，尤其当技术说明来自发现该漏洞的公司时。
Strix 表示，受影响镜像的日期为 2023 年 3 月 3 日。在 2026 年 7 月测试时，该凭证仍然有效。其长期存续使一个常见的构建错误演变为规模更大的访问控制失效。
范围严格、有效期短的凭证本可以限制损害。相反，据报道，该令牌将长期有效性与对多个敏感代码仓库的访问权限结合在一起。公共注册表提供了可发现性，而过度权限则带来了影响。
一次旧 Docker 构建保留了仍有效的密钥
该事件表明，从容器可见文件系统中删除密钥，并不一定意味着它已从镜像中消失。
容器镜像包含的不只是容器启动时可用的文件。它们还包括镜像层、配置数据、构建指令和元数据，这些内容可能揭示制品的组装方式。
在本案中，据报道，该密钥出现在镜像的构建历史中。构建过程将 GitHub 令牌作为参数接收，然后用它配置对私有依赖项的认证访问。
这种模式在开发期间看似合理。一次构建需要来自私有代码仓库的代码，因此工程师提供凭证并配置 Git 使用它。构建完成后，生成的应用似乎不包含任何明显的令牌文件。
但构建过程本身可能保留了被替换后的值。任何能够获取该镜像的人，都可能检查开发人员在正常运行时测试中很少查看的元数据。
Docker 当前的构建密钥指南明确指出，构建参数和环境变量不适合用于存储密钥。这些值可能保留在生成的镜像或其元数据中。
Docker 建议改用密钥挂载或 SSH 挂载。密钥挂载仅在需要凭证的构建指令执行期间提供该凭证。凭证无需成为镜像文件系统或已记录命令的一部分。
这一改动只解决了 Baseten 安全漏洞的一部分。据报道，相关 Dockerfile 模式还将经过认证的 GitHub URL 写入全局 Git 配置。即使采用更安全的注入方法，若使用该凭证的命令将密钥存储到其他位置，依然会失效。
因此，安全构建需要两项控制措施。团队必须通过临时机制注入凭证，然后验证使用凭证的命令不会再创建另一份持久副本。
镜像扫描也必须覆盖的不只是当前文件。传统扫描器通常会在镜像层中搜索可识别的凭证格式、存在漏洞的软件包或恶意二进制文件。完整审查还应包括配置 blob、历史字段、环境设置、溯源记录和导出的缓存。
旧镜像同样应受到审查。即使团队早已停止使用，注册表仍可能保留标签和制品。这些制品可能反映了早期的安全实践、更宽泛的权限，或无人记得撤销的凭证。
Strix 所述镜像已超过三年。Baseten 的平台、部署方法和安全计划在这段时间内可能已经发生变化。然而，这一旧制品据称仍可下载，并且关联着一个仍然有效的凭证。
这是一种常见的基础设施债务形式。应用不断演进，但被遗忘的构建输出仍然可被访问。当身份积累更多权限，或代码仓库变得更重要时，其风险可能进一步上升。
凭证管理又增加了一层暴露风险。GitHub 在其令牌指南中建议组织优先使用细粒度凭证，并设置到期日期。
细粒度令牌可将访问限制在选定代码仓库和特定操作范围内。对于长期运行的组织集成，GitHub Apps 也可提供另一种选择。与权限范围宽泛的个人凭证相比，其权限和令牌有效期可以得到更精确的控制。
据报道，basetenbot 令牌似乎同时违反了多项防御原则：有效期长、授权范围广、在构建期间嵌入，并且可通过公共注册表项目获取。
每一项弱点都放大了其他弱点。仅有注册表暴露，可能只会泄露一张旧镜像；仅有嵌入令牌，也可能难以获取。而宽泛的代码仓库权限，则使二者的组合成为严重发现。
这种叠加效应正是安全团队审查攻击路径、而非孤立配置错误的原因。一系列看似普通的失误，可能导致没有任何单一组件原本打算授予的访问权限。
Baseten 的快速响应降低了风险，但未消除信任问题
据报道，Baseten 在一天内控制住了即时暴露，但企业买方仍需要证据证明，类似凭证和制品并未遗留在其他地方。
Strix 于 7 月 13 日晚些时候报告了公开 Harbor 项目、仍有效的令牌及其权限。据披露信息显示，Baseten 于次日早晨将该项目设为私有。
随后，Strix 告知 Baseten，该 GitHub 令牌仍然有效。据报道，7 月 14 日晚些时候，Baseten 安全团队的一名成员将该问题定性为严重，并确认该令牌已被轮换。
Baseten 还要求 Strix 删除其已下载的镜像。Strix 表示已确认删除，并分享了另外两项严重性较低的发现。截至 7 月 17 日，Baseten 已关闭这些剩余事项。
这一响应迅速且直接。Baseten 似乎没有质疑所报告问题的严重性，Strix 也赞扬了该公司的安全团队在协作上的表现。双方在 Strix 于 9 月 1 日发布技术说明前进行了协调。
快速修复具有重要意义，因为对披露的处理方式反映了服务提供商的一部分运营成熟度。组织无法保证每一项制品和配置都始终没有错误，但可以控制验证、遏制、调查并从报告中学习的速度。
然而，轮换只会关闭已知凭证。它无法回答是否有人在 2026 年 7 月之前使用过该令牌、是否有人下载过该镜像副本，或相关构建实践是否影响了其他制品。
目前没有公开证据证明曾发生恶意利用。Strix 表示，其自身请求均为只读操作，并在确认代码仓库权限后停止。Baseten 尚未公开说明与该令牌相关的入侵、客户数据损失或未经授权的代码仓库变更。
不应将未报告滥用转化为没有发生滥用的证据。一项有意义的事件审查应检查 GitHub 审计事件、注册表下载日志、令牌活动、代码仓库变更，以及暴露窗口期间的部署情况。
审查还需要考虑保留期限的限制。日志可能无法覆盖镜像构建以来的整个期间。一个三年前的凭证，可能比重建其所有使用情况所需的遥测数据存续得更久。
Baseten 公开的安全条款说明，其在共享基础设施上对客户内容实行逻辑隔离。条款还提到，针对需要额外隔离的买家，可提供专用集群和客户自托管部署。
这些控制措施解决的是运行时数据隔离问题，但此次事件发生在平台周边的软件供应链中。代码仓库凭据和构建产物位于客户工作负载的上游，相关环节一旦遭到入侵，可能影响多个部署层级。
这正是核心的信任问题。企业买家评估的不仅是其推理请求是否经过加密或隔离，还必须评估谁能够修改处理该请求的软件、配置和自动化流程。
即使从未直接读取生产数据，拥有推送权限的令牌也可能威胁完整性。攻击者可能尝试篡改代码或部署定义，再等待正常的自动化流程将改动分发出去。
管理权限可能带来更广泛的后果，具体取决于代码仓库设置和组织政策。它可能允许修改权限、分支保护、webhook、密钥或自动化流程。Strix 并未测试这些具有破坏性的路径。
因此，对客户而言，风险并不局限于源代码机密性，还包括供应链遭操纵、运营中断，或通过恶意软件变更实现间接访问的可能性。
Baseten 值得肯定的是，其迅速遏制了已披露的攻击路径。但信任不能只建立在响应速度之上。客户还需要确信，该公司审查了相邻产物、缩小了凭据权限范围，并调查了历史访问情况。
这种保证可以来自直接的客户沟通、独立评估、审计证据，或更详尽的公开事后复盘。上述任何形式都不应要求公开会制造新攻击机会的信息。
正确的标准应是与风险相称的透明度。Baseten 无需披露每一项内部控制措施，但受影响的利益相关方应了解哪些内容曾暴露、审查了哪些日志，以及客户是否需要采取行动。
Neocloud 的速度正与 Hyperscaler 的预期发生碰撞
更大的问题并不是专业 AI 基础设施必然缺乏安全性，而是客户如今已开始期待更年轻的运营环境也具备云级别的控制能力。
Baseten 提供用于部署和提供 AI 模型服务的基础设施。这类推理工作可能涉及专有模型权重、提示词、客户记录、应用逻辑以及连接系统的凭据。
专业 AI 云服务商通过让团队更快获得加速器和托管推理能力展开竞争。与通用云相比，它们可以更专注于模型性能、部署速度和 GPU 利用率。
这种专业化并不会降低所需的安全标准。由于 AI 工作负载通常同时包含高价值知识产权和敏感运营数据，它反而可能提高安全要求。
Neocloud 这一标签涵盖不同的商业和技术模式。一些公司主要出租加速器算力；另一些则在自行运营或从大型云采购的基础设施上，提供托管训练、推理、编排或开发者平台。
因此，客户必须确认每一层由哪一方控制。相关链条可能包括数据中心运营商、硬件提供商、基础设施云、模型服务平台、容器镜像仓库、源代码托管方和客户应用。
某一层的失效可能波及其他层。Baseten 的安全漏洞并不需要攻击 GPU 或模型；它沿着常规网页发现路径进入镜像仓库，再从镜像元数据延伸至源代码控制权限。
这正是传统云安全控制措施仍然重要的原因。AI 基础设施可能采用先进加速器和专用网络，但暴露的镜像仓库、长期存在的密钥和过度授权依然是熟悉的问题。
近期一项行业审计认为，若干 neocloud 环境依赖薄弱的租户边界、过时组件或连接过度的管理系统。该报告也承认安全讨论中存在相关激励因素，并敦促读者审视底层证据。
Baseten 事件不同于该研究所描述的跨租户基础设施问题。目前没有公开演示表明一名 Baseten 客户曾访问另一名客户的活动工作负载。
相反，它揭示了供应链的集中化问题。据报道，单一自动化身份对产品、部署、分发以及客户专属代码仓库拥有重要访问权限。这种集中化扩大了单个泄露令牌可能造成的影响范围。
该事件还暴露出一种尴尬的竞争失衡。大型 hyperscaler 同样经历过严重漏洞、凭据泄露和配置失误，其规模并不能使其免疫。
不过，成熟服务商多年来一直在建设身份系统、审计工具、密钥检测计划和事件响应流程。企业客户越来越期望规模较小的 AI 服务商在更早的发展阶段就提供可比的证据。
需求将加剧这一压力。Gartner 在其市场预测中预测，到 2030 年，neocloud 服务商将占据 AI 云市场的重要份额。
增长同时扩大回报与攻击面。更多企业工作负载意味着更多身份、镜像、代码仓库、区域、集群和软件依赖项。安全计划必须覆盖并扩展至所有这些环节。
潜在客户将通过把对抗性测试纳入采购流程来应对。Strix 的扫描能力不同寻常，因为该买家本身就在开发自主渗透测试系统。大多数公司无法在内部复现这类审查。
但它们仍然可以提出更严格的问题。买家应要求了解镜像仓库控制措施、凭据生命周期政策、软件物料清单实践、事件通知条款和独立渗透测试摘要。
他们还应确认服务商是否将构建、部署和面向客户的身份相互隔离。用于获取依赖项的凭据不应管理生产代码仓库或部署定义。
合同保证依然有用，但架构和运营证据更为重要。一项政策可能要求最小权限原则，而一个旧的自动化令牌却仍在多个代码仓库中悄然保留访问权限。
持续的外部测试有助于发现这些缺口。它应补充经过授权的审查、代码分析、依赖扫描和内部威胁建模。黑盒测试能够看到未经身份验证的外部人员所能看到的内容，而内部评估则检查隐藏在公共界面之外的控制措施。
Strix 的角色带来一个必要的保留意见。该公司销售自主安全测试服务，而这起事件展示了其产品能力。因此，其技术叙述也服务于自身商业利益。
但这并不会使发现失效。详细时间线、有限的验证步骤、修复顺序以及据称与 Baseten 的协调，都增添了可信度。不过，由于令牌和镜像仓库暴露问题已被关闭，独立报道尚未复现最初的访问。
读者应将这项发现视为已披露且已修复的漏洞，而不是所有 neocloud 都存在同样弱点的证据。更广泛的教训关乎验证，而非一概不信任。
三个信号将显示这一教训是否真正被吸取
下一项考验在于，Baseten 及其同行能否将一次凭据泄露转化为构建系统、身份体系和客户保障方面的长期改变。
第一个信号是 Baseten 后续审查的范围。轮换 basetenbot 凭据并将一个 Harbor 项目设为私有，解决了已演示的攻击路径。持久的应对措施应盘点所有镜像仓库项目、历史镜像、构建缓存和自动化凭据。
这项工作应包括当前部署已不再引用的镜像。团队通常聚焦于活跃发布版本，因此旧标签往往逃过常规扫描。然而，攻击者可以利用任何包含有效密钥的可下载产物。
审查还应搜索镜像配置和构建历史。仅扫描文件系统会遗漏 Strix 所描述的位置。构建流水线需要在发布前设置关卡，拒绝层和元数据中包含密钥的内容。
第二个信号是身份体系重构。Baseten 可以通过以权限狭窄、生命周期短的凭据替代宽泛的个人访问令牌，降低未来的影响范围。
一个获取单项依赖的构建流程，只需要对该依赖的读取权限。它不需要对产品代码仓库、部署配置或无关客户项目拥有管理控制权。
服务商应按环境和用途隔离身份。构建、发布、部署、软件包分发和客户集成任务不应共用同一凭据。一个工作流遭到入侵后，应在经过刻意设计的边界处止步。
到期机制同样重要。长期存在的自动化密钥往往会在团队、代码仓库和架构变动后继续留存。短期凭据需要更完善的自动化，但能大幅降低遗忘副本的利用价值。
第三个信号是买家行为的变化。安全团队应越来越多地在发送模型、提示词、文档或源代码之前，扫描潜在的 AI 服务商。
并非每位客户都需要进行激进的渗透测试。未经授权的活动可能造成法律和运营风险。买家可以从获许可的外部评估、文档审查、访问控制验证和合同安全问题着手。
他们还应维护自身的防护措施。敏感模型资产和源材料在进入任何外部服务之前都需要进行分类。团队可以通过个人知识库记录服务商接收到的内容，再将该清单与供应商审查相连接。
客户应为服务商失效做好规划，而不是假定可以实现完美预防。这意味着限制上传的密钥、使用独立凭据、监控异常活动，并为关键工作负载保留退出路径。
Baseten 的安全漏洞呈现出一次明显的角色反转。原本应由潜在客户评估推理性能、可靠性和集成成本，但其初步安全检查却发现了对支持该供应商自身系统的访问权限。
Baseten 的快速响应强化了故事的一面。据报道，该公司接受了严重性评级、遏制了镜像仓库暴露问题、轮换了凭据，并在数日内关闭了其余发现。
尚未解决的一面是历史保证。公开信息无法证明是否还有其他人获取过该镜像、该令牌此前是否被不当使用，或 Baseten 对类似产物进行了多大范围的搜索。
这些未解问题不应由猜测填补，而应成为采购问题和审计目标。
对于 neocloud 而言，速度仍是一项重要优势。客户希望快速部署模型，并获得稀缺的计算能力。然而，当买家无法信任构建和运营基础设施的系统时，更快的基础设施也就失去了价值。
实际问题已不再是专业 AI 云服务能否在功能上逐项匹敌超大规模云厂商，而是它们能否在增长过程中展现出严谨的凭证管理、租户隔离和供应链控制能力。
Baseten 已关闭已知暴露点。接下来，客户应关注是否有证据表明，这一修复措施已超越单个令牌和单个注册表项目。这样的证据将决定此事是一次孤立失误，还是成为更广泛 neocloud 市场未能吸取的警示。
