一次投毒，偷走整个云的钥匙

开发者机器上最不该出事的工具，正在变成最危险的入口。2025年6月，Zscaler ThreatLabz 披露：有攻击者在官方 Terraform Registry 上发布了名为 terraform-provider-bunnynet 的恶意 Provider，一套两阶段恶意软件顺着 IaC（基础设施即代码）工具链流进开发者环境：先偷云凭据，再拿远程控制权。报告认为这可能是 TraderTraitor 组织的新动作，但归属证据并不完整。真正值得行业记住的是：攻击者已经从偷 npm 包，进化到偷你管理云的那把钥匙。

🪝 两段式投毒：先偷钥匙，再拿房子

一场教科书式的供应链攻击，讲究的是耐心。

这次事件的载体不是应用代码，而是 Terraform Provider——开发者用来创建云资源、配置基础设施的插件。Provider 的特殊之处在于：它天然持有云 API 权限，运行在 CI/CD 流水线和工程师本地环境里，而且一旦引入，往往长期无人复查。

根据 ThreatLabz 的公开报告，攻击者上传的 terraform-provider-bunnynet 仿冒了 bunny.net 官方 Provider 的命名与功能描述，发布在官方 Terraform Registry 上，随后被多平台开发者下载执行。恶意代码植入后，攻击链分两段展开。第一段载荷名为 FLATROOF，负责凭据窃取和建立初始访问——简单说，先把云账号的钥匙偷出来。第二段载荷 ROOFDECK 随后登场，提供更广泛的远程控制能力，让攻击者在目标环境里站稳脚跟。

这套「先偷凭据、再上远控」的两段式设计，暴露了攻击者对云环境的理解：在现代基础设施里，一份有效的云凭据比一个漏洞 exploit 更值钱。漏洞需要绕过，凭据开门就走。

攻击是跨平台的，意味着 macOS 和 Linux 上的开发者工作站都在射程之内——而这两类系统，恰恰是大多数基础设施团队的主力工作环境。

🕵️ 归属存疑：为什么「像」不等于「是」

安全圈有句老话：归因是最昂贵的一步。

ThreatLabz 的分析团队在报告中给出了初步判断：这次行动疑似与 TraderTraitor（一个以加密货币行业为目标的朝鲜背景攻击组织）有关。依据是目标选择、工具特征和战术手法上存在相似性。

但报告同时坦率承认了证据的缺口：没有唯一的代码匹配、没有共享基础设施、没有密码学层面的关联证据。换句话说，这是「行为画像相似」，而不是「指纹吻合」。

这个细节值得所有安全从业者琢磨。攻击者越来越擅长「借壳」——故意复用知名组织的 TTP（战术、技术与流程），让防御者和威胁情报团队把精力引向错误的方向。当 APT 归因可以误导对手的资源投放时，战术层面的模仿本身就是一种武器。

对企业的启示很实际：与其纠结「是谁干的」，不如盯住「怎么进来的」。这次事件的入口是投毒的 Provider，这条路径无论归属哪个组织，防御动作都一样——锁定依赖来源、校验完整性、监控凭据滥用。近年公开报告的供应链事件中，「手法撞车但无法坐实归属」的案例明显增多，威胁情报正在从「给攻击者贴标签」转向「给攻击路径建模」——这一趋势在 Mandiant、Recorded Future 等机构对多次事件的归因说明中均有体现。

🔗 IaC 为什么成了下一个必争之地

低频高价值的入口，永远是攻击者的优先目标。

回看开源供应链攻击的演进路径：早期是 typosquatting（仿冒包名）和账号劫持，瞄准的是应用依赖；后来 SolarWinds 式的事件证明，连安全厂商自己的更新通道都能被利用；而现在，攻击面正在向 IaC 和 CI/CD 工具纵深推进。

Terraform 被投毒之所以是标志性事件，在于它打通了两条价值链：

第一，Provider 直接操作云 API。一次成功的投毒，等于在所有使用该 Provider 的环境里预置了一个「合法的」云操作通道。云凭据一旦泄露，攻击者可以创建新资源、修改安全组、导出存储桶——全程看起来都像是管理员在正常操作。

第二，IaC 代码天然具备传播性。一个被广泛引用的 Provider 模块，可能同时存在于数千个仓库和流水线中，污染一次，收割一片。

从这次事件的选型逻辑看，攻击者的商业判断已经非常清晰——「哪里持有最高权限、哪里审查最少，就打哪里」。IaC 工具恰好两个条件都满足。这不是孤例：2023 年 publiusfarah 事件中，攻击者就是通过伪造 Terraform 模块在 GitHub 上实施投毒，相关分析可参考 Trend Micro 与 CNCF 的公开复盘。

对厂商而言，这也是一次警钟：HashiCorp 生态以及各类 Registry 平台，需要把「Provider 与模块的完整性验证」当作一等公民能力，而不是文档里的一行 best practice。

🛡️ 防御市场分化：三条路线已经清晰

攻击在进化，防御侧的产业格局也在快速收敛。

软件供应链安全市场目前大致分成了三个流派。第一条是「消灭问题」路线，以 Chainguard 为代表，提供硬化过的零 CVE 基础镜像——思路是与其修补漏洞，不如直接换用持续维护、无已知漏洞的镜像源头。第二条是「入口拦截」路线，以 Sonatype 为代表，在依赖进入构建环节之前就完成风险评分与阻断。第三条是「溯源证明」前沿，以 Scribe 和 Lineaje 为代表，用来源证明和完整性证明（attestation）回答「这个构件到底从哪来、有没有被改过」。

这四类攻击面——依赖、流水线、构件、基础镜像——恰好对应了这次 Terraform 投毒事件里几乎每一个环节：被投毒的 terraform-provider-bunnynet 是「依赖」，投毒发生的 Registry 分发渠道是「流水线」问题，FLATROOF 与 ROOFDECK 载荷是「构件」，而开发者机器上的执行环境则接近「基础镜像」的范畴。

从 Gartner 对软件供应链安全（Software Supply Chain Security）的持续跟踪看，这一领域「是一个披着品类外衣的综合性战略」——没有单一工具能覆盖全部风险面，采购决策的本质是判断自己最薄弱的是哪一环。

🧭 给企业落地：三件事比买工具更急

工具解决不了流程缺位的问题。

回到这次事件，多数组织的当务之急其实只有三件事。第一，审计 Terraform Provider 及所有 IaC 依赖的来源与版本锁定，确认没有引入未经校验的版本——具体到本次事件，应在代码库中全量检索 terraform-provider-bunnynet 与命名空间 BunnyNET-BUYNOW，确认未曾引用。第二，把云凭据从开发者工作站和流水线的明文环境中剥离，改用短期凭据与工作负载身份，让 FLATROOF 这类窃取型载荷「偷到也没用」。第三，在 CI/CD 中引入制品签名与来源校验（如 Sigstore cosign、SLSA attestation），让被篡改的 Provider 在执行前就暴露。ThreatLabz 报告附带的 IoC 清单（恶意 Provider 的命名空间与版本、载荷哈希、C2 基础设施）可在其官方 GitHub 仓库（Zscaler/ThreatLabz）获取，建议直接核对并接入威胁情报源。

这三件事分别对应了市场上三条防御路线的核心能力。换句话说，这次事件给供应链安全市场做了一次最好的需求教育——高曝光供应链事件后的一个季度，相关工具的企业询价出现明显抬头，这在 Sonatype 与 Snyk 历年的《State of the Software Supply Chain》类报告中已有数据支撑。

但也要警惕另一个极端：把供应链安全当成又一个「买个盒子就完事」的合规项。投毒攻击打的是信任链，信任链的管理是持续运营，不是一次性采购。

小结

一次 Provider 投毒，偷的不只是几份云凭据，而是暴露了整个 IaC 生态的信任假设过于脆弱。TraderTraitor 的归属或许永远不会被坐实，但攻击路径已经清晰可见：从仿冒的 terraform-provider-bunnynet，到 FLATROOF 窃取的凭据，再到 ROOFDECK 的云端控制权。防御侧的三条路线——消灭问题、入口拦截、溯源证明——正在成形，选型逻辑也开始从「功能对比」走向「攻击面对齐」。可以预见，2026 年之后，IaC 与 CI/CD 工具链的完整性验证，会像今天的镜像扫描一样成为标配。下一场供应链攻防的主战场，已经写在了这一刻的事件报告里。