npm 包被植入恶意代码 (event-stream)：为什么一个开源包的「换人维护」，会成为攻击者最省事的入口？

# 商业复盘备忘录：npm 包被植入恶意代码 (event-stream)

> 为什么一个开源包的「换人维护」，会成为攻击者最省事的入口？
> 周期: 2018 - 2018 | 行业: 工具与互联网
> 巅峰: 被广泛使用的开源工具包，周下载量以百万计，被大量项目作为基础依赖引入，属于生态里典型的「默默运行」型组件
> 终局: 原维护者把项目转手后，新维护者在依赖中植入针对特定加密货币钱包的恶意代码，被平台发现前已发布数月，引发对开源维护权转让的广泛讨论

## 核心概览
接手一个被广泛依赖的包，比攻破任何一家公司都便宜。巅峰期被广泛使用的开源工具包，周下载量以百万计，被大量项目作为基础依赖引入，属于生态里典型的「默默运行」型组件；终局是原维护者把项目转手后，新维护者在依赖中植入针对特定加密货币钱包的恶意代码，被平台发现前已发布数月，引发对开源维护权转让的广泛讨论。

## 社区公投头号死因
1. [外部合规] 维护权可以低成本转让给陌生人 (919 票)
2. [产品技术] 使用者对间接依赖缺少可见性 (772 票)
3. [资本财务] 开源维护缺少持续支持 (625 票)

## 可执行教训
### 依赖链每多一层，审查就多一层盲区
> 你信任的不是那个包，是那个包背后的所有人。

- ✅ 推荐做 (DOs):
  - 对间接依赖做定期审计并收敛不必要的依赖
  - 对关键依赖的维护者变更保持关注
- ❌ 绝不能做 (DON'Ts):
  - 不要把「开源免费」当作无需投入
  - 不要对多层间接依赖视而不见

## 救亡方案
### 收敛依赖并审计维护者变更，再谈引入新包 — 良略编辑部
干预时点: 2018 年 11 月确认依赖链中存在恶意代码时
- 必须断腕:
  - 立即移除受影响版本并排查钱包相关调用
  - 停止在缺少审计的情况下引入多层间接依赖
  - 停止对关键依赖的维护者变更视而不见
- 破局动作:
  - 对全部依赖做一次完整审计并收敛数量
  - 对关键依赖的维护者变更建立监控与复核
  - 对涉及密钥与资金的调用路径做独立隔离
- 预期结果: 恶意代码在进入生产环境前被发现，团队对依赖链有清晰掌握，敏感操作与第三方代码隔离。

## 社区见解
### 攻击者最省事的方式，不是攻进你的系统，而是接过你依赖的那个包。 — 良略编辑部 (工程师)
这个包的维护者是一个长期无偿投入的个人，倦怠之后把项目交给了一个陌生接手者——在开源生态里，这是完全正常的交接。问题在于使用者对此毫无感知：多一层的间接依赖，就让恶意代码落在了大多数团队的视野之外，而这些代码专门盯着使用这条依赖链的钱包。整个过程从转让到被移除，持续了数月。
- 如果重来一次的纠偏招式 审批依赖时，除了看代码，也要看它的维护者是谁、最近换过人没有。

---
来源: 良略 · https://www.lianglue.com/c/event-stream-npm