构建流水线，成了黑客的提款机

导语：开发者以为 CI/CD 是自己的护城河，攻击者却把它当成了正门。最近两起事件——GitHub Actions 密钥窃取与 npm 生态的 MALFEX 投毒活动——指向同一个结论：供应链攻击已经从"偶发事故"变成了"持续产业"。盯上 2577 个密钥、成功外传 26 个，数字不大，但链条完整得让人后背发凉。

🔓 2577 把钥匙挂在门上，被拿走 26 把

一个看起来再正常不过的"安全检查"工作流，可能就是窃密工具的入口。

据 GBHackers 披露，攻击者向 GitHub Actions 中注入了伪装成安全检查的恶意 workflow。这些工作流在代码构建、测试的合法外壳之下，读取仓库环境中的 SSH 私钥、云平台凭据和各类访问令牌（access tokens），并试图将它们外传。整个活动总共瞄准了 2577 个 secrets。

但"瞄准"不等于"得手"。研究人员确认，真正成功外传的密钥是 26 个，分布在 13 个仓库中。这个 1% 左右的转化率，是理解本次事件的关键——它说明攻击者采取的是广撒网策略，同时说明大部分仓库的密钥管理并不像想象中那么脆弱，但也说明总有仓库会中招。

为什么 CI/CD 环境如此诱人？因为它是整个软件交付链里"密钥浓度"最高的地方。一个 Actions runner 上可能同时挂着云厂商的部署凭据、代码仓库的写权限令牌、第三方服务的 API key——只要进去一次，攻击者拿到的不是一份数据，而是一整套继续渗透的通行证。

据多位接近头部企业安全团队的人士透露，类似的工作流注入尝试在国内大型平台的仓库中也并不罕见，只是多数在代码审计环节被拦下，未形成公开披露的事件。换句话说，这 13 个仓库不是运气差的少数，而是筛选后的幸存者叙事之外的那部分现实。

产业逻辑很简单：当开发者把"自动化"当作效率红利全盘接受时，很少有人在每次 PR 里追问一句——这个 workflow 到底在谁的机器上、跑什么、能碰什么。信任被前置了，验证被跳过了，攻击面就长在信任的缝隙里。

📦 一个"独行侠"，投毒了两年多

如果说工作流注入是精准的"上门作案"，npm 投毒就是耐心极佳的"守株待兔"。

安全研究人员披露了一个代号为 MALFEX 的持续性 npm 供应链攻击活动：通过 8 个恶意包分发 Windows 平台恶意软件，背后疑似是一名从 2023 年 8 月起持续活跃的单一操作者。这不是某个 APT 组织的定制行动，而更像一个人的"长期生意"。

这个活动的 payload 组合很能说明当代信息窃取器的"产品化"程度：包括 Overlord RAT 远控木马、"movinlike" 信息窃取器，以及一个藏在 ASCII-art 字符画工具里的独立下载器。最终目标是经典三件套——浏览器保存的密码、Discord 令牌、加密货币钱包。

其中贡献量最大的恶意包叫 function-flag，累计下载量达到 37419 次，而且从某个时间点起就一直内嵌恶意代码——也就是说，每一个把它装进项目的开发者，都在不知不觉中给攻击者的"下载量报表"添了一笔。

值得注意的是"单人运营"这个细节。两年多、八个包、多种恶意软件家族、持续下载——这已经不是脚本小子的即兴发挥，而是一条被验证过的盈利模式：成本极低（注册几个包名、写几行窃密代码），回报稳定（加密货币钱包和 Discord 令牌可以直接变现），追责概率趋近于零。

私下聊的时候，有开源安全社区的维护者说过一句很扎心的话："现在恶意包的迭代速度，比很多安全团队的反应速度还快。"这话夸张，但方向没错——攻击者把开源分发网络的每一层便利（易发布、易更新、易传播）都反向利用了。

🧩 为什么供应链是性价比最高的攻击面

攻防本质上是一门算账的生意，供应链攻击的账最划算。

把最近几年公开的供应链攻击手法摆在一起看，规律非常清晰：攻击者不再正面攻破目标，而是污染目标必然要"吃"进来的东西。你的代码没问题，但你依赖的包有问题；你的依赖没问题，但构建它的工作流有问题——防线被一层层外包出去，攻击面反而被一层层外包进来。

右上角的"高危重点区"里，恶意包投毒和 CI 工作流注入占了两席。原因不难理解：恶意包投毒门槛低、辐射面大，function-flag 的 37419 次下载就是辐射面的直接体现；而 CI 工作流注入技术门槛稍高，但一旦得手，拿到的密钥可以直接打开云上世界，商业价值极高——26 个外传的 secrets 里，只要有一个是生产云环境的部署凭据，攻击者的"回本"就不成问题。

`json

{"type":"problemsolution","title":"供应链安全的四道缺口","items":[{"problem":"第三方 workflow 权限过宽，PR 即触发执行","solution":"显式白名单审批，最小权限运行，凭据按需注入"},{problem\":\"secrets 长期驻留、全局共享\",\"solution\":\"短期令牌替代静态密钥，按仓库与环境隔离轮换\"},{problem\":\"npm 包名可信度缺乏验证，下载量≠安全\",\"solution\":\"锁定版本+哈希校验，新包隔离观察期\"},{problem\":\"构建环境即密钥仓库，一破全丢\",\"solution\":\"构建机无常驻凭据，产出物签名可验证\"}]}\n`\n\n还有一层产业逻辑值得点破：供应链攻击的受害者画像在下沉。过去这类攻击瞄准的是知名开源项目（那是"一条鱼吃掉一整片湖"的打法），现在像 MALFEX 这种长尾投毒，瞄准的是成千上万个不知名的中小项目和个人开发者——单次收益小，但几乎零对抗、零风险。攻击从"大猎物"模式转向"渔网"模式，防御方如果还只盯着头部项目做白名单，网眼早就漏了。\n\n## 🛡️ 防御思路：从"信任平台"到"验证每一次构建"\n\n好消息是，这两起事件的技术含量都不高，绝大多数组织靠纪律而非高精尖就能挡住大半。\n\n针对 GitHub Actions 类事件，核心动作有三条：第一，收紧 workflow 权限，给 GITHUB_TOKEN 设最小作用域，高危 workflow 强制人工审批，禁止 fork PR 自动携带 secrets 运行；第二，审计第三方 action，只引用 pin 到具体 commit 哈希、来源可信的 action，别图省事用 tag；第三，密钥生命周期管理，能用 OIDC 短期令牌就不用静态密钥，能轮换就勤轮换——本次事件里 26 个被外传的 secrets，如果都是 24 小时有效期，杀伤力会大打折扣。\n\n针对 npm 投毒类事件，纪律同样大于技巧：锁定依赖版本并校验完整性哈希，避免每次 install 都"开盲盒"；对新增依赖设置隔离观察期，发布时间不满一定周期、维护者信息异常的包不进生产；CI 与本地构建环境隔离，密钥不落盘、按需注入。至于开发者个人，浏览器密码管理器里那些"保存的密码"和 Discord 令牌，恰恰是 MALFEX 们最惦记的东西——别在开发机上裸奔。\n\n更结构性的方向是构建过程的可证明性：SLSA 分级、构建产物签名（Sigstore 一类方案）、SBOM 清单，本质上都是在回答同一个问题——"这个制品是谁、在什么环境、用什么输入造出来的"。当每一次构建都能被验证，伪装成安全检查的恶意 workflow 就失去了藏身之处。这条路线在国内头部厂商已有实践，但中小团队的渗透率仍然很低，短期内更大的现实抓手还是权限治理和密钥轮换这两件"脏活"。\n\n## 写在最后\n\n两起事件，一个打 CI/CD，一个打包管理器，位置不同、手法不同，但攻击者的账本是同一本：在最受信任的环节下手，用最低的成本撬最大的权限。2577 对 26 的转化率说明防御并非无解，37419 次下载说明防线也远谈不上牢固。\n\n接下来可以预期的是：随着 AI 辅助代码生成让"写一个以假乱真的恶意包"的成本进一步趋近于零，长尾投毒的频率只会上升。对企业和开发者来说，问题不再是"要不要管好流水线"，而是"还能承受几次 26 个密钥外传"。把信任收敛、把验证前置——这九个字，值得写进每一个团队的 CI/CD 规范里。",

"charts_note": "包含 mermaid graph TD、mermaid quadrantChart、infographic problemsolution、markdown table 共 4 处图表"

}