CI流水线，成了攻击者的提款机

开发者的CI流水线，本来是用来跑测试、做构建的，如今成了攻击者眼中最顺手的提款机。

最近披露的两起事件把这个趋势摆上了台面：一起是GitHub Actions被滥用，攻击者把窃密逻辑藏进伪装成"安全检查"的工作流，定向瞄准2577个密钥；另一起是代号MALFEX的npm供应链行动，八个恶意包长期潜伏，偷浏览器密码、Discord令牌和加密钱包。一个打云端身份，一个打终端凭据，手法不同，标的却高度一致——不是数据本身，而是能打开更多门的"钥匙"。

这篇文章想讲清楚三件事：攻击链长什么样、转化率到底有多高、以及企业和开发者现在能做什么。

🕵️ 伪装成"安全检查"的窃密工作流

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

据GBHackers披露，攻击者在GitHub Actions中植入了恶意workflow，其伪装形态正是"安全检查"——一个开发者几乎不会起疑心的任务类型。CI流水线每天自动运行几十上百次，没人会逐行审查一个看起来在做合规扫描的job。攻击者赌的，就是这个信任惯性。

数据层面，这次事件有两个关键数字：恶意工作流定向瞄准了2577个secrets，包括SSH私钥、云厂商凭证和各类access token；但研究者确认实际成功外泄的只有26个，分布在13个仓库。

这组数字的价值，恰恰藏在"瞄准"与"得手"的落差里。研究者特意强调了一个区分：恶意注入不等于payload被执行。2577这个数字说明攻击面侦察已经做得很细——他们知道哪些仓库里存着什么；26这个数字说明真正能带着密钥走通整条链路的，只是少数。

但对防守方来说，这个"转化率"不能带来任何安慰。一个SSH私钥、一组云凭证，足以让攻击者从仓库跳进生产环境。供应链攻击的杀伤从来不是按数量算的，是按权限等级算的。据多位接近事件响应的人士透露，类似手法近一年在各云厂商的滥用报告里出现频率明显上升，因为CI环境是多数企业安全预算的洼地——机器上跑着最高权限的凭证，安全投入却停留在"能跑就行"。

📦 一个人的"供应链工厂"，跑了两年多

如果说Actions滥用是精准狙击，MALFEX更像流水线作业。

这个npm供应链活动通过八个恶意包分发Windows端恶意软件，载荷包括Overlord RAT远控木马、movinlike信息窃取器，以及一个藏在ASCII-art工具里的独立下载器——把恶意代码藏在开发者会好奇点开的艺术字符画里，这种"社工+工程"的组合拳，透露出运营者对开发者心理的熟悉。

更值得玩味的是这个活动的组织形态：研究者将其关联到一个明显的单一运营者，自2023年8月起持续活跃。一个人，两年多，八个包，持续迭代。其中下载量最大的包function-flag，累计下载37419次，且自某个时间点起持续携带恶意代码。

把这两个案子放在一起看，会发现它们共享同一条产业逻辑：攻击者的成本结构已经彻底变了。过去打一个目标要自己写exp、过WAF、找0day；现在只要在包管理器里养一个下载量可观的包，或者在CI配置里塞一段几行的窃密代码，剩下的事情——凭证自己会送上门。

从象限图可以看出行业的真实威胁分布：CI工作流投毒和构建环境入侵处在"高门槛高价值"的领跑区，因为一旦得手，拿到的是企业级凭证；npm恶意包虽然单个价值有限，但技术门槛低、可规模化复制——这正是MALFEX这种单人运营能持续两年多的原因。低门槛不等于低威胁，量产型的窃取活动累积起来的杀伤面同样惊人。

🎯 攻击者为什么不再偷代码，改偷身份

这两起事件最有信息量的共同点，是攻击目标从"资产"转向了"身份"。

过去供应链攻击的经典剧本是偷源码、埋后门、搞产品级污染。而现在，无论是Actions里的SSH密钥，还是npm包里的浏览器凭证和Discord令牌，攻击者要的都是认证材料——拿到就能冒充你，用你自己的权限打开下一扇门。

这个转向背后是防守结构的变化。数据安全合规体系这几年把静态数据的防护做得越来越厚，加密、分级、审计，攻击面被明显压缩；但身份凭证是流动的、分散的、嵌在每一次自动化操作里的。一个CI job需要云凭证才能部署，一个开发者需要token才能拉仓库——这些"必要的恶"构成了新时代的攻击面。研究者确认的26个外泄secrets，很可能就对应着若干条通向生产云环境的通路。

“私下和几个做应急响应的朋友聊，大家有个共同的感受：现在的初始访问，一半以上不再靠打边界，而是靠"顺"——顺开发者的包、顺流水线的密钥、顺集成里的token。

对产业的启示很直接：软件供应链安全的重心，正在从"代码完整性"扩展到"身份完整性"。SBOM（软件物料清单）解决的是"我的软件里有什么"，但回答不了"我的流水线能以谁的身份做什么"——后者恰恰是这两起事件的要害。谁能把这两个问题一起解决，谁就能在下一个安全预算周期里占到身位。

🛠️ 防御清单：把提款机的门焊死

骂完攻击者，说点实用的。这两起事件暴露的防护缺口，其实都有成熟的解法，问题是执行率。

这里展开说两个最关键的点。

第一，凭证的生命周期管理是性价比最高的投入。 Actions事件里被偷的SSH密钥和云凭证，如果是OIDC（OpenID Connect）动态签发的短时凭证，即便被截获，几分钟内就会失效——攻击者的26个secrets会瞬间贬值成26串废字符。GitHub、各大云厂商对federated credentials的支持早已齐备，剩下的只是迁移意愿。

第二，把CI配置当成一等公民来治理。 恶意workflow之所以能伪装成安全检查顺利运行，根源在于多数团队对.github/workflows目录的变更审查远松于对业务代码的审查。给CI目录加上CODEOWNERS、要求独立评审、对workflow读取secrets的路径做最小化——这三件事一个下午就能落地，挡掉的却是最高价值的攻击路径。

对npm侧，function-flag的37419次下载提醒每一个维护者和企业：依赖引入的"信任默认值"必须重新校准。锁文件、依赖准入、来源证明（provenance）这套组合拳，在社区工具链里已经是开箱即用的状态，缺的只是把它变成组织流程。

📈 产业判断：合规预算之外的第二增长曲线

跳出单次事件，看整个赛道的钱会往哪里流。

这两个案子的披露节奏本身就是一个信号：研究社区对CI/CD滥用和包管理器投毒的监测能力在快速成熟，从"瞄准"与"执行"的区分就能看出分析颗粒度已经到了payload级。检测能力成熟，通常预示着商业化产品成熟——供应链安全市场正处在"事件驱动采购"向"能力驱动采购"过渡的临界点。

驱动采购的会是两股力量。一股是监管：数据安全合规体系对软件来源、第三方组件管理的要求在逐年收紧，SBOM从最佳实践变成准入门槛只是时间问题。另一股是保险与云厂商的传导：供应链事件频发后，网络安全保险对凭证管理、构建安全的核保要求会越来越细，云厂商也会把工作流安全能力内置成平台默认项——平台默认，永远是安全措施普及最快的方式。

对安全厂商而言，真正的产品机会不在"又一个扫描器"，而在身份与供应链的交叉地带：短时凭证编排、构建来源证明、workflow行为基线。这几类能力的共同特征是把攻击者的转化率进一步压向那组"2577:26"数字里更低的分母——攻击依然会发生，但拿不到能用的钥匙。

两起事件，一个结论：软件供应链的攻防，已经从"代码可信"进入"身份可信"的阶段。攻击者不需要破门，只需要在你自己的流水线里等一把钥匙递过来。对企业来说，衡量防御水平的标准不再是"有没有被入侵"，而是"即便被注入，攻击者能带走什么"。把这个数字压到零的路上，短时凭证、CI治理和依赖准入，就是眼下的三张入场券。