1. 旧模式：“基于数量的恶意软件”
最初，攻击者关注的是数量：
- 向 npm/PyPI/Maven 推送恶意软件包
- 域名抢注（例如，伪造热门库的版本）
- 品牌盗用和明显的冒充
- 低成本恶意软件，依赖于用户意外安装。
这种攻击会产生大量噪音，容易被检测到，并且越来越多地被扫描程序和注册表防御机制过滤掉。
2. 新模式：“信任滥用”
攻击者现在追求的是可信度而不是攻击数量。他们没有试图用明显是假的包裹来欺骗用户，而是：
- 损害或模仿受信任的维护者和发布工作流程
- 将恶意软件注入看似合法的软件包中
- 滥用CI/CD 流水线和自动化发布系统
- 将恶意代码隐藏在依赖项和安装脚本中。
- 利用“受欢迎=安全”的假设
攻击者越来越多地利用以下漏洞：
- 受信任的软件包名称
- 可信发布路径
- 可信工作流程
3. 为什么这更危险
这种转变改变了攻击特征：检测概率降低，恶意代码现在包括：
- 熟悉的包装
- 通过正常更新发布
- 乍一看往往与正版发行版难以区分
更高影响，攻击者不必只感染一个开发者，而是可以：
- 到达整个依赖树
- 损害 CI/CD 管道
- 从构建系统中窃取令牌、凭证和密钥
4. 攻击者现在实际的目标是什么
这篇文章强调，真正的目标不仅仅是应用程序，而是软件构建过程本身：
- 开发人员机器
- 构建服务器（CI/CD）
- 环境变量和 API 密钥
- 发布基础设施
一旦恶意软件在这些环境中执行，它就可以窃取凭据或持久存在于下游版本中。
5. 真实案例
近期发生的一些事件来说明这一趋势：
- SANDWORM_MODE：多阶段、自适应恶意软件，针对开发工作流程
- Trivy/LiteLLM 妥协：滥用可信工具和发布路径
- axios依赖项事件：微小的依赖项变更导致更广泛的风险
这显示出一种模式：攻击者不需要“新花样”——他们只需要访问受信任的分发渠道。
6. 主要结论
核心信息是：安全不再仅仅是检测“恶意包裹”，而是验证“看似安全的包裹”是否真的安全。或者更直白地说：旧世界：“这个包裹是恶意的吗？”新世界：“这个值得信赖的包裹是否在供应链的某个环节被悄悄地改动了？”
7. 这在未来为何重要
防御措施必须在流程的早期阶段就发挥作用：
- 安装前扫描
- 控制依赖源（代理仓库）
- 检查传递依赖关系
- 将开发/持续集成环境视为高价值目标
- 强制执行持续验证而非一次性信任