一条流水线，正在偷走你的密钥

开发者信任链，正在变成攻击者的提款链。

过去一周，两条独立的安全线索同时浮出水面：一边是攻击者滥用 GitHub Actions，把恶意代码伪装成安全检查流程，瞄准了 2577 个密钥与凭证；另一边是一场代号 MALFEX 的 npm 供应链行动，从 2023 年 8 月起持续投放恶意包，偷浏览器密码、Discord 令牌和加密货币钱包。

两件事看似无关，内核却完全一致：开发基础设施的信任链，正在被系统性武器化。CI/CD 流水线和包管理器，是开发者最高权限凭证的聚集地，也是防御最薄弱的环节之一。

🎯 Workflow 里的“安全检查”，其实是钓鱼钩

最危险的后门，往往伪装成安全产品。

这次的 GitHub Actions 事件中，攻击者把恶意 Workflow 伪装成安全检查任务。开发者看到一条流程在跑静态扫描、依赖检查，视觉上毫无异样，便放心地让它在仓库环境里执行。而这个环境里，恰恰存放着 SSH 私钥、云厂商凭证、各种第三方服务的 Access Token。

Workflow 一旦执行，恶意逻辑就开始在环境变量和文件系统中翻找密钥，随后外传。研究者确认了攻击链条的完整闭环：从注入到执行，再到数据外带。

数据是残酷的。这次行动瞄准了 2577 个 secrets，但“瞄准”不等于“得手”——研究人员最终确认成功外泄的只有 26 个，来自 13 个仓库。

也就是说，转化率只有约 1%。但请不要因此松口气：1% 的命中率，在攻击者的成本模型里依然是划算的。因为目标基数可以持续扩大，注入成本几乎为零，而每一个被偷走的云凭证，都可能直接通向一家公司的生产环境。

这个案例还有一个容易被忽略的细节：恶意注入和有效载荷执行是两件事。很多企业的安全监控只关注“仓库里有没有可疑提交”，却不去验证“Workflow 实际执行了什么”。研究者之所以强调这个区分，正是因为大量注入代码可能根本没跑起来——但只要有一条跑了，就够攻击者喝一壶。

📦 一个人的“包工厂”，跑了两年多

如果说 Actions 事件是精准狩猎，MALFEX 就是流水线作业。

MALFEX 是一场持续的 npm 供应链行动，通过八个恶意包分发 Windows 恶意软件。据分析，幕后疑似只有一名运营者，从 2023 年 8 月活跃至今。这打破了很多人对供应链攻击“一定是高水平 APT 组织”的想象——一个人、一台电脑，就能长期经营一条恶意分发渠道。

其投放的载荷包括三种：远控木马 Overlord RAT、信息窃取器 movinlike，以及藏在一个 ASCII 艺术工具里的独立下载器。偷什么？浏览器保存的密码、Discord 令牌、加密货币钱包——全是开发者个人账户里最值钱的东西。

其中下载量最大的包叫 function-flag，累计 37419 次下载，并且“自某时点起就已包含恶意代码”。这意味着这批恶意代码在 npm 生态里裸奔了相当长的时间，几万名开发者在毫无察觉的情况下安装了它。

🔑 为什么开发者身份成了最佳突破口

攻击者不傻，他们只打性价比最高的地方。

把两条线索放在一起看，会发现攻击者的目标高度重合：先偷开发者的个人凭证，再顺着凭证爬进企业。浏览器密码、Discord 令牌、云密钥——这些看似“个人资产”的东西，往往就是企业边界的钥匙。一位开发者用浏览器登录了公司云控制台，用 npm 账号维护着核心依赖，他的个人电脑被拿下，等于半个企业被拿下。

这也是近两年供应链攻击的明显演化：攻击重心从“偷一个库的代码”转向“偷一个人的身份”。传统的防御思路是保证开源组件“代码干净”，但现在的攻击根本不需要污染代码逻辑——它们只需要在安装脚本或 CI 流程里多跑几行命令，去读环境变量和密钥文件。

据多位接近事件响应一线的从业者私下透露，企业在排查此类事件时最大的痛点是资产不清：哪些仓库的 Workflow 会读取 secrets？哪些流水线绑定了长期有效的云凭证？没有人能第一时间回答。排查往往从“发生了什么”开始，却卡在“我们到底暴露了什么”上。

两条攻击线的对比如下：

🛡️ 防御不是玄学，是清单问题

好消息是，这类攻击的防御手段是成熟的，缺的只是执行。

针对 CI/CD 凭证外泄，有三件事值得立刻做。第一，最小化 secrets 暴露面：审查每个仓库的 Workflow 是否真的需要读取全部 secrets，把长期云凭证换成短期、限定权限的 OIDC 联邦凭证——攻击者即便偷到，令牌也可能已过期。第二，锁定 Workflow 权限：给每个 Workflow 显式声明最小 permissions，关闭默认的宽泛授权，并对拉取请求触发的流程保持警惕，尤其是来自 fork 的改动。第三，监控执行而非只监控提交：关注 Workflow 实际执行了哪些命令、是否有异常的网络外联，而不是仅仅盯着 diff 记录。

针对 npm 恶意包， developers 需要改变“顺手就装”的习惯。安装前看一眼包的下载量、发布时间和维护者历史——一个注册不久、维护者信息模糊、却声称解决常见需求的包，天然值得怀疑。企业侧则应建立内部制品库（如私有 registry 代理与白名单），对进入生产依赖树的包做准入审查。Overlord RAT 这类载荷依赖的是“装了就跑”的默认信任，切断这个默认信任，攻击成本就会陡增。

平台责任同样绕不开。GitHub 和 npm 近年持续收紧：强制双因素认证、引入可信发布（provenance）机制、加速下架恶意包。但据接近平台生态治理的人士透露，恶意包的“上架—被发现—下架—换名重上”循环始终存在，平台治理本质上是攻防双方的运营消耗战，技术手段只能压缩攻击者的生存窗口，无法归零。

💡 写在最后：信任链需要重新定价

安全行业喊了多年“零信任”，但喊话的对象多是企业网络。现在轮到开发基础设施了。

GitHub Actions 的 26 个被窃密钥和 npm 上 37419 次恶意下载提醒我们：开发者工具链的默认信任，必须被重新定价。CI 流水线不该天然拥有全部凭证，npm 包不该装完就能读浏览器数据，每个环节的权限都应该是“申请来的”，而不是“默认给的”。

对个人开发者，今晚就可以做的事是：清理浏览器里保存的公司相关密码、给云凭证设过期时间、检查自己维护的仓库里哪些 Workflow 能碰 secrets。对企业，则要把 CI/CD 凭证治理纳入正式的安全清单，而不是等事件响应时才临时盘点。

攻击者已经完成了对开发者信任链的系统性定价，防御一方该跟上节奏了。下次当你看到一条“安全检查”流程在流水线上安静地跑着，不妨多问一句：它到底在检查什么，又在读取什么。