CI流水线，成了偷密钥的新金矿

开发者以为自己在写代码，其实是在给攻击者递交钥匙。

最近两起披露的事件，把开源供应链攻击的靶心清清楚楚地画了出来：一起是 GitHub Actions 恶意工作流批量窃取 SSH 私钥、云凭据和访问令牌；另一起是代号 MALFEX 的 npm 持久化战役，用八个恶意包搬运 RAT 和信息窃取器。前者偷的是组织资产的信任链，后者偷的是开发者终端上的浏览器密码、Discord 令牌和加密钱包。

这不是巧合，是同一场产业变迁的两个切面。当 CI/CD 成为软件工厂的传送带，传送带本身就成了最好的下手地点。

⚙️ 一场伪装成「安全检查」的偷窃

最讽刺的攻击，往往披着防御的外衣。

据 GBHackers 披露，攻击者向 GitHub 仓库注入了伪装成安全检查的恶意 workflow。这些工作流看起来人畜无害——跑个 lint、做个扫描、输出一段日志——实际上在流水线执行过程中，静默读取仓库运行环境中挂载的机密信息：SSH 私钥、云厂商的 API 凭据、各类 access token，然后打包外传。

数字值得细看。这批恶意工作流的-targeting-范围覆盖了 2577 个 secrets。但「瞄准」不等于「命中」：研究人员最终确认成功外泄的只有 26 个密钥，分布在 13 个仓库中。

两个数字之间的落差，恰恰是本次事件最有信息量的地方。它揭示了一条被很多安全报告刻意模糊的因果链——

恶意注入不等于恶意执行。一个被投毒的 workflow 如果因为分支保护、workflow 权限收紧或者流水线根本没跑起来，密钥就不会真正离开环境。安全团队在应急响应时必须区分「潜在暴露面」和「实际泄露面」——前者决定要不要整改，后者决定要不要换钥匙、要不要止损上报表。

但这 26 个确认外泄的密钥，已经足够点燃一条完整的入侵链。一个云凭据可以直接通向云上资源，一个 SSH 私钥可以直接落进内网。据接近事件处置的人士透露，这类凭据失窃的复盘难点在于：workflow 日志里混进了大量噪音，很多团队直到凭据被用在别处才知道自己已经失血。

📦 npm 上那个「耐心的猎人」

如果说 GitHub Actions 事件是精确的撬锁，MALFEX 更像是多年磨一剑的蹲守。

据披露，MALFEX 是一场持续运作的 npm 供应链战役，通过八个恶意包向 Windows 用户投递恶意载荷。链路背后的操作者疑似只有一个人，且从 2023 年 8 月起就活跃至今——将近两年的持续运营，在动辄「打了就跑」的投毒事件里并不常见。

战役的货架上摆着三件货：远程控制木马 Overlord RAT、代号 movinlike 的信息窃取器，以及一个藏在 ASCII-art 工具里的独立 downloader。窃取目标直指开发者终端上的高价值资产——浏览器保存的密码、Discord 令牌、加密钱包。

其中体量最大的是 function-flag，累计下载量达到 37419 次，并且从某个时间点起就持续携带恶意代码。

这个案例值得所有做开源治理的人停下来想三分钟：3.7 万次下载，意味着 3.7 万次「正常开发者基于正常判断做出的正常安装决定」。没有鱼叉邮件，没有勒索谈判，没有任何需要突破的边界——信任本身就是攻击面。

一位在云厂商安全团队工作的朋友私下聊过，他们内部对这类事件的判断标准很朴素：单个包下载量过万、维护记录异常稀疏、功能定位「方便到可疑」的依赖，一律进人工审核名单。行业里甚至流传一句半开玩笑的话：npm 上活得最久的恶意包，往往不是写得最精的，而是名字起得最让人不想怀疑的。

🔑 密钥为什么成了供应链攻击的命门

两起事件手法不同，终点却高度一致：偷密钥。

这不是偶然。过去几年，企业安全的重心从「守边界」滑向「管身份」，云计算和 DevOps 让凭据成为一切权限的实体化形态——一个 access token 就是一张直接放行的门禁卡。攻击者摸清了这个变化：与其啃 hardened 的边界，不如等开发者自己把门禁卡放进流水线。

对比两起事件的差异，产业逻辑会更清晰：

注意最后一行的差别。npm 投毒偷到 Discord 令牌和浏览器密码，看起来像是「个人资产」级别的损失，但开发者终端往往同时是公司代码库和云控制台的登录入口——2023 年以来多起震惊行业的事件都证明，开发者个人设备上的一个令牌，可以直接兑换成企业生产环境的一把钥匙。

所以供应链攻击的杀伤模型其实是两级火箭：第一级偷开发者手里的凭据，第二级用凭据进入企业核心。MITRE ATLAS 和各家威胁情报团队反复强调的「SaaS 与 CI 令牌是新兴主战场」，说的就是这件事。

🛡️ 防御实战：给流水线装三道闸门

抱怨供应链不安全没有意义。真正有用的问题是：怎么把上面两条攻击链的成本抬高到攻击者划不来？

从两起事件的机理反推，防御至少要覆盖三个层面。

第一道闸门：workflow 与依赖的准入。

GitHub Actions 的教训是，仓库里能被外部注入的 workflow 必须收敛。优先给仓库配 GitHub 官方推荐的 workflow 权限基线（默认只读 GITHUB_TOKEN）、对 fork PR 的 secrets 暴露做隔离、启用 workflow 执行审批。npm 侧则是在依赖引入环节建立来源评估：下载量、维护者历史、包功能与体积的合理性，都可以做成自动化评分。

第二道闸门：密钥的寿命管理。

既然偷的目标是凭据，就让凭据变得「偷了也不值钱」：短生命周期 token、按流水线任务最小化授权、OIDC 短期联邦凭据替代长期 API key、敏感密钥定期轮换。26 个确认外泄的密钥里，如果有几个是有效期只有十五分钟的临时凭据，事件的止损成本会低一个量级。

第三道闸门：出口与终端。

工作流和构建机的外联行为要做出口管控——构建环境本不该把数据发往陌生的收集端点。开发者终端则要纳入企业 EDR 的视野，因为 MALFEX 交付的 RAT 和窃取器在终端层面是可以被行为检测逮住的。

三道闸门对应三个可以量化的 KPI：workflow 权限基线覆盖率、长期凭据存量下降率、构建环境外联异常告警闭环时长。据多位接近大型开源平台运营方的人士观察，真正把这三件事做成常态的团队，在同类事件里的应急成本会明显低于同行——不是他们更聪明，而是他们让「一次成功的注入」换不回「一次有效的执行」。

🧭 小结

GitHub Actions 上 2577 个被瞄准的 secrets、最终确认外泄的 26 个密钥，以及 npm 上那个下载近 4 万次的恶意依赖，共同指向同一个判断：软件工厂的传送带，已经成为攻击者的首选入口。CI/CD 凭据与开源依赖，是这场攻击经济学里投入产出比最高的两个杠杆点。

前瞻一点看，随着 AI 辅助生成依赖包和自动化 workflow 的门槛进一步降低，投毒的「产量」只会更高。防御方的胜负手不在检测某一次攻击，而在于把准入、凭据生命周期和出口管控做成流水线的默认选项——让信任链上的每一环，都必须重新证明自己值得信任。

对每一个开发者而言，答案朴素到近乎扫兴：少装一个不必要的包，给流水线上的密钥设个短寿命。金矿就守在你自己手里，别再把它递出去了。