大家好，我是DevOps攻城狮。
最近读了一份挺有意思也挺震撼的报告：JFrog发布的《2025软件供应链现状报告》。这是JFrog连续多年基于其平台数据、CVE趋势分析、安全研究团队研究和1400位开发/安全从业者调查所形成的一份行业报告。
我挑了一些对我们DevOps从业者、尤其是负责CI/CD和软件交付的人来说非常有参考价值的内容，分享如下：
软件供应链，真的变了#
报告开头就给出了几个数字，让人警觉：
- 64% 的企业开发团队使用 7种以上编程语言，44% 使用10种以上；
- 一个普通组织 每年引入458个新包，也就是每月平均38个；
- Docker Hub 和 Hugging Face 上的镜像和模型数量仍在指数级增长；
- npm依然是恶意包的“重灾区”，但 Hugging Face 上的恶意模型增长了6.5倍。
如果说过去我们担心“你用的包有没有CVE”，现在可能得先问一句：
你真的知道自己用了哪些包、拉了哪些模型吗？
风险激增，不只来自漏洞#
2024年，全球共披露了 33,000多个CVE，比2023年多了27%。但这只是“冰山一角”。
报告揭示了一个更加令人担忧的趋势：“漏洞≠风险”，而“风险”正在从更多方向袭来：
- 秘钥泄露：JFrog在公开仓库中扫描出 25,229个秘密token，其中 6,790个是“活的”；
- XZ Utils后门：攻击者假装是OSS维护者，潜伏多年后埋入后门，影响OpenSSH；
- AI模型的投毒：某些Hugging Face模型在加载时自动执行恶意代码（Pickle注入），悄无声息入侵机器；
- 误配置的代价：比如微软Power Pages因权限配置问题泄露大量用户数据，Volkswagen旗下公司因SaaS误配置泄露了80万台电动车的定位数据。
说实话，这些问题和“有没有扫描CVE”没什么关系。很多时候，是我们根本没意识到“这里也会出事”。
AI爆发，风险也同步升级#
今年Hugging Face新增了超过100万个模型和数据集，但同时，恶意模型也增长了 6.5倍。很多组织都开始将AI模型纳入业务，但：
- 有 37%的企业靠“人工白名单”筛选模型使用；
- 很多AI模型使用的是Pickle格式，加载即执行，一不小心就中招；
- Hugging Face等平台上也出现了“挂羊头卖木马”的开源模型。
对于我们DevOps或者平台团队来说，这意味着：
“模型”正在变成新的“依赖包”，也应该纳入供应链治理和安全扫描的范畴。
安全实践现状：工具变多，人却更焦虑#
报告里还有一个很现实的观察：
安全工具越多，反而让人越看不清真相。
- 73%的企业使用了 7个以上安全工具，但只有 43%同时扫描代码和二进制；
- 71%的组织允许开发者直接从公网拉包；
- 52%的组织一边允许公网拉包，一边又靠自动规则追踪来源；
- CVSS评分“虚高”问题越来越严重，JFrog分析后发现，88%的Critical CVE其实并不适用。
作为一线DevOps，我看到的是：工具越来越多，但我们似乎并没有真正“安心”下来。
我们能做什么？#
报告里没有提供“万无一失”的解决方案，但给出了一些务实建议，我结合自己的理解补充几点：
- 治理从源头做起：不要再让开发者从公网自由拉包，使用内部代理仓库如 Artifactory/Nexus/Harbor；
- 扫描不止于代码：二进制扫描、容器镜像扫描和SBOM（软件物料清单）都需要纳入CI流程；
- 引入“适用性评估”：别光看CVE得分，更重要的是它是否真的适用于你的场景；
- 把AI模型当“依赖”管理：构建模型白名单、扫描模型安全性，甚至做模型SBOM；
- 限制新“匿名包”引入：不要因为某个库“突然火了”就引入，回顾XZ事件足够令人警醒。
写在最后#
2025年的软件供应链比以往更大、更快、更复杂，也更脆弱。
安全问题不是“有没有风险”，而是“你知道风险藏在哪里吗”。 一不小心，风险可能来自一个新同事引入的PyPI包，或者一位AI工程师下载的模型。
JFrog这份报告虽然没有解决所有问题，但给我们敲了一个不小的警钟。
如果你也在构建自己的DevOps流程、AI平台、或者仅仅是维护日常构建环境， 建议你认真想一想：
你的“依赖”到底靠不靠谱？ 你的“扫描”真的能发现问题吗？ 你的“策略”是否跟得上变化了？
欢迎在评论区聊聊你看到的“供应链怪现象”。也希望这篇分享对你有所启发。
🧡 欢迎关注，一起做更好的技术实践。 📥 如果你需要这份《JFrog Software Supply Chain Report 2025》原报告， 可以在公众号后台回复关键词：“jfrog report 2025” 来获取报告下载链接。
转载本站文章请注明作者和出处，请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」