开源数据监控工具 elementary-data 出了一个很具体、也很刺眼的问题：0.23.3 版本被植入窃密代码。
这个版本同时出现在 PyPI 和项目 Docker 镜像账户里。约 12 小时后，它被移除。项目方给出的安全替代版本是 0.23.4。
我更在意的不是“又有一个依赖包出事了”。这次麻烦在于，攻击者不是等用户系统里出现漏洞再利用，而是借项目自建 GitHub Action 的缺陷，拿到了发布令牌和签名密钥，把恶意版本当成正常版本推了出去。
这类事最容易被一句“月下载量超过 100 万”带偏。这个数字只能说明包的使用面不小，不能推出已有 100 万用户受害。真正要查的是：你的机器、CI/CD runner、容器构建流程，有没有在那 12 小时窗口内安装或运行过 0.23.3。
受影响范围很窄，但命中的团队要按泄露处理
目前确认受影响的是 elementary-data 0.23.3。安全版本是 0.23.4。
这句话要拆开看。范围窄，不代表风险低。它窄在版本号；它高在运行环境。
| 项目 | 已确认情况 | 使用者该怎么做 |
|---|---|---|
| 受影响版本 | elementary-data 0.23.3 | 安装或运行过就排查 |
| 安全版本 | elementary-data 0.23.4 | 显式固定到该版本 |
| 发布渠道 | PyPI 与 Docker 镜像账户 | Python 依赖和容器流水线都要查 |
| 未受影响范围 | Elementary Cloud、Elementary dbt package、其他 CLI 版本 | 不要扩大到全部 Elementary 产品 |
恶意代码盯上的不是无关紧要的本地文件。公开信息提到的目标包括 dbt profiles、数据仓库凭据、云服务密钥、API token、SSH key，以及 .env 文件内容。
对数据团队来说，这些就是进数仓、云账户和内部 API 的钥匙。对平台团队来说，这些也可能是 CI/CD 里为了省事提前挂好的通行证。
所以，安装过 0.23.3 的团队不宜只做“卸载重装”。更稳妥的判断是：凡是当时运行环境能读到的凭据，都先按已经暴露处理。
真正的分界线在 CI/CD，而不是开发者电脑
个人电脑中招当然要查，但 CI/CD runner 更危险。
原因很直接。很多流水线会把云厂商密钥、制品库 token、部署凭据、数据库账号放进环境变量或配置文件里。恶意 CLI 一旦在这里执行，拿到的就不一定是单个开发者权限，而可能是一串能横跨构建、发布和数据访问的权限。
这也是它和普通依赖漏洞的差别。普通漏洞往往还需要攻击者找到利用路径。供应链投毒则把恶意代码伪装成正常更新，直接进入自动化流程。
2021 年 npm 生态的 ua-parser-js 被接管，2024 年 xz Utils 后门事件，提醒的是同一件事：开源项目的维护与发布流程，本身已经是攻击面。防线不只在代码审查，也在谁能触发流水线、流水线能拿到什么密钥。
最相关的两类人，动作也不一样。
数据团队要暂停对 elementary-data 的自动升级，确认版本后再恢复任务。只要跑过 0.23.3，就要轮换 dbt、数仓和云服务相关凭据。
平台和安全团队要查构建日志、镜像缓存、runner 环境变量和密钥访问记录。尤其要看 PyPI 安装记录、Docker 镜像拉取记录、制品库访问记录，以及云账户和数据仓库是否出现异常调用。
现在要做三件事，也要看清一个约束
项目方称，第三方 issue 报告后约 3 小时内移除了恶意包，并轮换了恶意代码可访问的项目凭据。相关 GitHub Action 已修复，其他工作流也做了审计。
这些动作说明项目方处理得不算慢。但它不能替下游团队擦掉风险。恶意代码一旦在你的环境里执行过，项目方下架包也拿不回已经外流的密钥。
可执行动作可以压成三步：
- 查版本用
pip show elementary-data | grep Version确认是否为 0.23.3；同时检查 Docker 镜像标签、digest、构建日志和镜像缓存。 - 换版本移除 0.23.3，固定到
elementary-data==0.23.4，并清理本地依赖缓存和相关容器缓存。 - 换密钥轮换当时运行环境可访问的 dbt profiles、数仓账号、云密钥、API token、SSH key 和 .env 中的敏感内容。
还可以查一个执行痕迹。macOS/Linux 下看 /tmp/.trinny-security-update，Windows 下看 %TEMP%\.trinny-security-update。如果这个文件存在，说明载荷曾执行过。
这里有个现实约束：目前公开信息不足以判断攻击者身份，也不能确认下游入侵规模。不要把“下载量大”直接等同于“受害者多”。
接下来更该盯的是另一件事：还有多少开源项目允许外部 PR 触发高权限 GitHub Actions，又把发布令牌、签名密钥和外部贡献代码放在同一条流水线里。
HD Moore 提到，可以用 zizmor 这类工具扫描 GitHub Actions 风险。工具能帮忙找坑，但不能替代权限设计。发布令牌不该被普通 PR 触发路径读到，签名密钥也不该和未信任代码共享上下文。
对工程团队来说，这起事件给出的判断很硬：热门开源包不能只看下载量、Star 或维护活跃度。更要看发布流程是否可审计，CI/CD 权限是否最小化，依赖更新是否先经过隔离环境验证。
包可以重装。流水线里那串没人复查的 token，才是更贵的账。