产品可以是干净的，而构建链却是有毒的。
这是现代软件供应链事件的惨痛教训。公司可以编写仔细的代码，使用流行的软件包，依赖签名的来源，并且仍然通过对普通工具来说看似合法的途径接收恶意代码。
2026 年 5 月，Hacker News 报道称，与 Mini Shai-Hulud 活动相关的 TanStack 供应链攻击影响了两台 OpenAI 员工设备，并强制 macOS 更新。 OpenAI、TanStack、StepSecurity、Snyk 和其他公司的公开报告描述了一场以凭证为中心的恶意软件活动，其目标是开发人员机器、CI/CD 工作流程、npm 包和下游消费者。
本文使用公开报告和供应商指南。它不包含任何受影响公司的私人信息。
每个产品团队的教训都是直接的。构建系统是生产的一部分。开发人员设备是攻击面的一部分。包来源有帮助，但它不能取代运行时行为审查、秘密卫生和响应证据。
公开报道的内容
Hacker News 于 2026 年 5 月 15 日报道，OpenAI 披露其企业环境中的两台员工设备受到 TanStack 上的 Mini Shai-Hulud 供应链攻击的影响。 OpenAI 表示，没有任何用户数据、生产系统或知识产权受到未经授权的损害或修改。作为预防措施，OpenAI 还轮换了多个产品的代码签名证书，建议 macOS 用户在 2026 年 6 月 12 日截止日期之前进行更新。
TanStack 发布了一份后续报告，称该事件涉及发布路径和恶意软件包版本的泄露。 StepSecurity 报告称，TeamPCP 推出了新一波 Mini Shai-Hulud，破坏了合法的 npm 软件包，并使用劫持的 CI/CD 路径发布恶意版本。 Snyk 报告称，2026 年 5 月 11 日 19:20 至 19:26 UTC 期间，在 Hacker News 命名空间中的 42 个软件包中发布了 84 个恶意 npm 软件包工件。
StepSecurity 表示，此次攻击使用劫持的 OIDC 代币通过该项目自己的 GitHub Actions 发布管道发布了恶意版本。 Snyk 强调，恶意软件包具有有效的 SLSA Build Level 3 来源，因为构建管道本身被劫持了。这一点很重要。来源正确地表明该包来自预期的构建系统。预期的构建系统是问题所在。
一些公开文章将凭证盗窃描述为主要目标。报告的目标包括 GitHub 令牌、云凭证、SSH 密钥、CI/CD 机密、开发人员工具文件和 AI 编码助手配置路径。
为什么这个案例很重要
现代开发依赖于共享包。单个 Web 应用程序可以提取数百或数千个直接和传递依赖项。团队使用 GitHub Actions、npm、包来源、OIDC、签名、容器、机密管理器、AI 编码工具、桌面应用程序和开发人员笔记本电脑。每一块都有助于加快速度。每个部分都会创建一条需要控制的路径。
TanStack 案例很重要，因为它位于这些路径的交叉点。
受影响的软件包被广泛使用。恶意版本是通过看似合法的基础设施发布的。下游消费者可以将它们安装为正常开发或 CI 的一部分。开发人员凭证和本地机密成为有价值的目标。该事件涉及一家拥有大量安全资源的人工智能公司，这证明即使对于成熟的团队来说，风险也存在相关性。
商务翻译很简单。如果您的产品依赖于开源软件包和自动化构建，那么您的安全轮廓包括维护者、CI 运行者、软件包注册表、令牌、本地工作站、签名身份和开发人员工具。
攻击路径如何运作
公共研究描述了一场滥用构建和发布基础设施的活动。确切的链条因报道而异，但防御模型是稳定的。
合法的软件包生态系统受到损害。恶意软件包版本已发布。安装这些版本的开发人员或 CI 系统可能会执行凭据窃取行为。该恶意软件搜索秘密和令牌。一些报告描述了开发人员工具和人工智能编码助手配置中的持久性挂钩。被盗的凭据可能有助于该活动扩散到更多的包中或到达内部存储库和云帐户。
这意味着第一台受感染的机器可能不是最终目标。有价值的目标可以是下一个代币、下一个存储库、下一个维护者帐户、下一个包或下一个 CI 工作。
这就是供应链响应必须采取行动的原因。删除包装只是第一步。团队还需要检查机器、轮换机密、查看 CI 日志、检查包锁定文件、验证存储库活动并查找异常包发布。
损坏情况如何
围绕 OpenAI 的公开报告称，没有任何用户数据、生产系统或核心知识产权受到未经授权的损害或修改。这很重要，应该保留。
更广泛的风险类别仍然很严重。
第一类损害是凭证暴露。开发人员计算机通常保存 GitHub 令牌、包令牌、SSH 密钥、云配置文件、API 密钥、环境变量、密码管理器会话和临时凭证。一台机器可以提供对许多系统的访问。
第二类是存储库暴露。即使只读访问也可以泄露架构、内部服务、过去意外提交的秘密、部署模式、产品计划、安全工具和客户特定的逻辑。
第三类是签约和分销风险。 OpenAI 的证书轮换说明了代码签名身份的重要性。如果攻击者可能滥用签名材料或在签名工件周围造成混乱，则用户和客户需要快速澄清。第四类是下游爆炸半径。流行的软件包同时存在于许多公司中。恶意版本可能会在数小时内影响产品团队、CI 工作人员、测试环境、开发人员笔记本电脑、临时系统和构建缓存。
第五类是审计压力。供应链事件发生后，客户会询问安装了哪些软件包、何时、何地、谁有权访问、轮换了哪些机密、在窗口期间构建了哪些版本以及最终产品是否受到影响。
第六类是AI工作流程曝光。开发人员工具现在包括人工智能助手、本地代理、编辑器集成、提示、模型密钥和自动化挂钩。修改这些路径的凭据窃取包可以在正常清理过程中幸存下来并在日常工作期间重新激活。
为什么普通控件会错过这个类
许多团队依赖包信誉、锁定文件、签名提交、CI 权限、出处和自动依赖关系扫描。这些控制措施有帮助。他们也有盲点。
当合法软件包受到损害时，声誉就会受损。
当恶意版本在允许的更新窗口期间进入或落在瞬态分支中时，锁定文件会失败。
当批准的构建管道创建不良工件时，来源会失败。
当恶意行为是新的、混淆的或在安装脚本期间传递时，依赖项扫描会失败。
当开发人员计算机管理松散或可疑行为看起来像正常的包工具时，端点检测会失败。
当本地文件、CI 日志、shell 历史记录、应用程序缓存或编辑器插件中也存在令牌时，秘密管理器会失败。
答案是分层证据。包策略、行为分析、受限 CI 权限、秘密轮换、开发人员端点控制、注册表监控和事件运行手册必须协同工作。
团队现在应该检查哪些内容
从依赖项清单开始。识别公共事件窗口期间受影响包的直接和传递使用。检查包锁定文件、npm 缓存、CI 日志、容器构建日志、开发人员计算机和工件存储库。
检查安装脚本。在安装过程中执行代码的包值得特别审查。在 CI 中尽可能禁用生命周期脚本。对需要它们的包使用允许列表。
限制 CI 令牌。 OIDC 代币和包发布代币应该是短期的、范围狭窄的，并且与特定的工作相关联。构建系统不应为每个工作流程提供广泛的注册表或云权限。
分离构建和发布权限。拉取请求构建不应具有与签名发布构建相同的秘密访问权限。测试工作流程不应该能够发布生产工件。
监控包发布。针对新软件包版本、异常发布时间、维护者变更、意外出处、安装脚本更改以及突然的依赖关系图变化发出警报。
强化开发人员端点。开发人员笔记本电脑需要 EDR、磁盘加密、设备管理、本地秘密控制、浏览器会话卫生以及 AI 编码助手和插件的明确规则。
有纪律地轮换。如果开发人员计算机或 CI 运行程序可能执行了恶意包，请轮换可从该环境访问的所有机密。其中包括 GitHub 令牌、npm 令牌、云密钥、SSH 密钥、API 密钥、包注册表凭据、CI 机密以及签名材料（如果可能泄露）。
保留证据。记录受影响的包、检查的机器、审查的日志、轮换的机密、更改的工作流程以及验证的发布工件。
CI
更安全构建链的控制模型
更安全的构建链从权限边界开始。
开发版本应该有有限的秘密。发布版本应该在受控的工作流程中运行。包发布应该需要狭窄的令牌、指定的维护者、受保护的分支和审查。云部署应该需要单独的权限路径。签名应有单独的保护和强有力的审核。
一个有用的控制模型将五种权限分开：
- 代码权限：谁可以更改源代码。
- 建立权威：哪些工作流程可以创建工件。
- 发布权限：哪些工作流程可以发布包或版本。
- 部署权限：哪些工作流程可以到达生产基础设施。
- 签名权限：哪些系统可以创建用户会接受的工件。
当一个通证或一个工作流程承载多种权限时，供应链事件就会变得更大。窃取广泛范围令牌的恶意包可以从开发人员工作站移动到存储库，从存储库移动到 CI，从 CI 移动到程序包注册表，以及从程序包注册表移动到客户。
减少这种运动。保持权力狭窄。让工作保持短暂。让日常测试工作流程中的秘密远离。需要对发布作业进行更严格的审查。
开发人员轮廓中的 AI 工具
AI编码工具改变了本地工作站。他们添加插件、代理、模型键、上下文窗口、本地缓存、编辑器挂钩，有时还添加后台进程。关于现代供应链恶意软件的公开报告描述了人们对人工智能编码助手配置路径的兴趣，因为这些路径可以保存有用的秘密或创造持久性机会。
团队应将人工智能工具视为开发人员安全轮廓的一部分。
这意味着盘点批准的人工智能工具、控制扩展、检查本地存储、保护 API 密钥、限制涉及敏感数据的存储库上下文，以及监视意外的配置更改。它还意味着定义人工智能助手在事件响应期间可以访问的内容。当团队试图控制存储库上下文时，受感染的开发人员机器不应继续将存储库上下文发送到外部工具。这是实践纪律。产品团队可以使用人工智能工具并仍然保持控制。公司需要规则、监控和证据。
团队和投资者在供应链案例之后会问什么
认真的团队希望从源代码到发布的产品有一条直接的路线。
他们询问如何批准依赖关系。他们询问包裹是否已固定。他们询问如何检测恶意软件包。他们询问是否允许安装脚本。他们询问哪些 CI 工作流程可以发布。他们询问秘密是如何存储的。他们询问开发人员端点是否受到管理。他们询问如何保护代码签名。他们询问公司能够以多快的速度从清洁状态重建。
投资者提出了相关问题。如果产品变得有价值，公司能否大规模保护发布路径？
含糊的回答会减慢谈话的速度。明确的证据包可以加快速度。该包应包括依赖性策略、CI 权限模型、秘密轮换过程、端点管理状态、发布签名控制、事件运行手册和最近的审核结果。
这些证据创造了商业实力。该团队认为公司可以快速发货，同时又不会失去对产品创建路径的控制。
认证应涵盖哪些内容
对于软件供应链轮廓，SToFU Systems 安全认证可以命名存储库、CI/CD 系统、包管理器、工件注册表、签名路径、开发人员端点控制、AI 编码工具、秘密存储和发布工作流程。
审查应包括可利用性问题。恶意依赖项可以读取什么？哪些工作秘密会暴露给拉取请求？哪个工作流程可以发布？哪些代币可以在一份工作之外继续存在？哪些机器可以存放签名材料？哪些人工智能工具可以访问私有代码？哪些日志证明受感染的软件包确实运行或未运行？
认证还应列出材料变更触发因素。新的注册表、新的发布系统、新的人工智能编码助手、新的签名流程、主要存储库迁移或新的云部署路径都应该重新进行审查。
这使证书保持有用。它成为构建链的活生生的证明，而不是静态的营销工件。
SToFU Systems 如何应对此类风险
SToFU Systems 将软件供应链作为产品安全轮廓的一部分进行审查。我们连接应用程序代码、依赖风险、CI/CD、秘密、发布权限、开发人员设备、云访问、AI 工具和审查就绪工件。
对于供应链事件和准备情况审查，我们可以提供以下帮助：
- 跨存储库和构建系统的依赖关系和包清单。
- CI/CD 对 GitHub Actions、OIDC、包发布、云访问和签名的权限审查。
- 跨开发人员机器、CI工作人员、存储库、环境、日志和工件存储的秘密暴露映射。
- 对安装窗口、锁定文件、缓存、容器和发布工件进行恶意包影响审查。
- 开发人员端点审查，重点关注凭证、编辑器插件、AI 工具、本地代理和持久性路径。
- 对签名工件、包来源、证书轮换和客户更新指南进行发布完整性审查。
- 补救计划和复测。
- 审查轮廓准备好后进行证据包装和安全认证。
该证书很有用，因为供应链问题现在出现在企业销售和投资者尽职调查中。团队想知道供应商是否能够证明代码如何从开发人员机器转移到生产工件。
产品团队的响应计划
如果您的团队得知图表中的某个包已被泄露，请快速采取行动并保持工作有序。
冻结受影响的构建。暂停使用受影响的依赖关系窗口的版本，直到团队验证工件。
识别暴露情况。搜索包锁文件、pnpm 锁、yarn 锁、npm 缓存、CI 日志、容器层、工件存储库和开发人员安装历史记录。
隔离机器。任何在窗口期间执行恶意软件包的主机都值得端点审查。开发者笔记本电脑和 CI 跑步机都重要。
轮换秘密。轮换可访问的凭据，从包注册表令牌、GitHub 令牌、云密钥、SSH 密钥、CI 机密以及在暴露可信时签署材料开始。
查看存储库。查找异常访问、新工作流程、修改的操作、更改的发布脚本、新的部署密钥、新的维护人员和意外的包发布。
从干净状态重建。清理依赖关系，删除受损版本，重建工件，并在可行的情况下比较输出。
用证据进行沟通。客户和合作伙伴需要冷静的事实：受影响的产品、受影响的版本、时间窗口、补救措施、凭证轮换以及任何所需的用户操作。
团队信号
TanStack 案例表明，供应链安全已成为产品可信度的中心。如果公司无法解释如何控制依赖项、构建、秘密和发布，那么公司可能会在没有生产违规的情况下失去利益相关者的信心。
最强大的团队会在被问到之前回答。他们会知道他们使用哪些软件包。他们将知道哪些工作流程可以发布。他们会知道秘密在哪里。他们将知道人工智能工具是如何管理的。他们将知道如何旋转、重建和证明结果。
SToFU Systems 有助于创造这种状态。检查构建链。减少权力。寻找曝光。验证发布路径。验证轮廓。
软件发展很快。证据必须随之移动。
