在 OWASP Top 10:2025 里，Software Supply Chain Failures 排在 A03，也就是第 3 位。它可以理解成“软件供应链失效”：风险不再只是“依赖里有漏洞”，而是从依赖、构建、仓库、IDE、CI/CD、制品、更新发布到生产部署的整条链路，只要有一个环节被投毒、失管、篡改或长期裸奔，最后都会变成你的应用风险。OWASP 在 2025 版里明确把它从 2021 年的 “Vulnerable and Outdated Components” 扩展成了更大的风险类别，说明现代软件最危险的地方之一，已经不是你自己写的业务代码，而是你信任的那整条开发与交付链。
来源：OWASP Top 10:2025 Introduction
来源：A03:2025 Software Supply Chain Failures

你可以把它理解成：

• 你是否知道系统到底依赖了哪些组件、哪些传递依赖
• 这些组件是不是来自可信来源、有没有签名、有没有维护
• 构建机、代码仓库、制品仓库、容器仓库、CI/CD 有没有被正确保护
• 更新上线是不是可追踪、可验证、可回滚

如果这些问题答不上来，就不是“治理做得一般”，而是供应链已经处于不可信状态。

为什么它在 2025 被提得这么高
OWASP 官方说明，这一类问题在社区调查里是 最受关注的风险之一，而且它已经从“已知漏洞组件”扩大为“整个软件生态链的失守”。官方页面也强调：一旦这类问题发生，往往利用成本不高，但影响极大，因为攻击者不是直接打你的业务逻辑，而是借你信任的组件、工具或发布流程进入系统。

常见表现

• 不清楚自己到底用了哪些直接依赖和传递依赖。
• 使用过时、无人维护、不可更新或已知存在漏洞的组件。
• 不定期扫描依赖漏洞，也不订阅相关安全公告。
• 代码仓库、制品仓库、镜像仓库、构建脚本变更没有审计。
• 开发者可以一个人“写代码 -> 构建 -> 发布到生产”，没有职责分离。
• 从不可信来源下载依赖、插件、镜像、脚本或工具链。
• CI/CD 的安全性反而弱于生产系统本身。
• IDE、构建插件、SaaS 集成、日志系统、制品生成过程没有纳入供应链治理。

OWASP 官方典型场景

• 受信任厂商被入侵，组织在升级时把恶意内容一起拉进来，典型代表是 SolarWinds 事件。
• 厂商或钱包软件只在特定条件下触发恶意逻辑，平时看起来一切正常。
• npm 生态里的恶意包通过 post-install 脚本窃取敏感信息、npm token，并继续传播到更多包。
• 某个组件和应用拥有相同权限，因此组件里的漏洞一旦被利用，后果就直接等于“应用被打穿”，比如 Struts2 RCE、Log4Shell 这类问题。

怎么防

• 建立并持续维护 SBOM（软件物料清单）。
• 不只跟踪直接依赖，也要跟踪所有传递依赖。
• 持续监控 CVE、NVD、OSV 等漏洞情报，并结合自动化工具扫描。
• 只从官方或可信来源获取依赖，优先使用签名包和可验证来源。
• 删除不用的依赖、功能、组件、文件和文档，减少攻击面。
• 强化代码仓库、开发机、构建机、CI/CD、制品仓库的访问控制，启用 MFA 和最小权限。
• 建立变更追踪机制，至少覆盖：CI/CD 设置、代码仓库、开发 IDE、SaaS 集成、日志系统、制品仓库、容器仓库。
• 上线时避免一次性全量推送，优先使用分阶段发布或金丝雀发布。
• 把“长期监控、持续升级、及时修补”当成应用生命周期的一部分，而不是季度任务。

一句话总结
Software Supply Chain Failures 的本质是：你把不够可信、不可验证、不可追踪的软件依赖和交付链，当成了可信基础设施来使用。