博通 TrueSource 将人工验证带入企业开源软件安全

博通在拉斯维加斯举行的 VMware Explore 2026 上发布了 TrueSource by Broadcom，这是一个面向企业的商业支持型开源软件组合，核心卖点是“可验证地构建”软件，并为企业提供持续的安全维护。13

TrueSource 将 Spring、更多软件制品、容器镜像和数据引擎纳入同一套支持与安全策略。博通传递的信息很明确：人工智能可以帮助发现漏洞、分析依赖关系并提出补丁，但在修复进入生产环境之前，代码、构建过程和实际运行影响仍应由负有责任的工程师进行验证。

TrueSource 包含什么？

TrueSource 目前由三项商业支持服务组成。

1. Spring Enterprise

Spring Enterprise 面向使用 Spring 生态的企业。该服务提供由 Spring 开发和维护团队整理的 Spring 版本，并包含主动式依赖扫描、经过人工验证的补丁，以及覆盖受支持版本线的协调修复。13

对于依赖大量传递依赖库的应用团队而言，这种定位并不只是“发现漏洞后逐个升级软件包”。博通希望将 Spring Enterprise 打造成与上游生态保持联系的版本维护和修复服务，帮助企业在更完整的依赖关系中处理安全问题。

2. TrueSource Trusted Artifacts

TrueSource Trusted Artifacts 将这一思路扩展到 Spring 之外。博通表示，该服务为 5,000 多个经验证 Java 库提供隔离环境构建，并达到 SLSA Build Level 3；同时还将覆盖范围扩展至 Java、Python 和 Node.js。服务还包括与 Spring Boot 版本精确对齐的组件，以及加固版 Bitnami 容器镜像。13

对平台团队和安全团队来说，重点在于来源可追溯和版本一致性：软件制品在受控环境中构建，与受支持的软件版本保持对应，并可作为从分散供应链中随意拉取未经验证依赖的替代方案。

3. TrueSource Data Services

TrueSource Data Services 覆盖四种常用数据引擎：PostgreSQL、RabbitMQ、MySQL 和 Valkey。博通称，该服务将可信软件制品、商业支持、部署专业能力、自动化工具，以及安全可见性或安全态势仪表板结合在一起。13

这意味着 TrueSource 并不只是一个面向代码库的安全产品。它同样瞄准企业在部署、升级和监控开源数据基础设施时所承担的运维压力。

TrueSource 如何授权？

这些服务采用分层的站点授权模式。按照博通的说法，商业模式增加的是技术支持、构建验证、修复获取和运维专业能力，并不改变底层开源软件原有的许可证。拥有合适产品授权的符合条件客户，还可以将部分非公开漏洞提交给博通，以提前获得修复支持。13

换句话说，企业购买的不是底层社区代码本身，而是围绕开源软件提供的责任主体、生命周期服务和运维保障。

为什么博通认为软件供应链压力正在上升？

博通将 TrueSource 放在企业软件供应链风险不断扩大的背景下进行介绍。如今，企业不仅需要保护自身编写的代码，还需要管理应用中使用的依赖库、容器和数据服务。博通援引的数据称，Spring 每月安全通告数量增长超过 1,700%，并以此说明 Spring 用户面临的修复工作量正在增加。3

博通提出的应对方式包括：

• 由工程师整理和维护的软件组件与版本；
• 在隔离环境中进行可验证构建；
• 自动分析代码仓库及漏洞影响范围；
• 生成建议性的修复拉取请求；
• 在适当情况下向上游项目贡献修复；以及
• 通过仪表板展示已解决和仍存在的暴露面。13

其重点并不只是“尽快打上补丁”。博通表示，企业还需要了解漏洞具体在哪里被使用，选择风险更低的修复路径，验证修复后的结果，并让修复继续与负责该项目的维护者保持联系。

AI 可以加速维护，但生产修复仍需人工把关

博通并没有否定 AI 辅助安全工作的价值，而是试图区分两件事：利用模型提高分析和补丁开发速度，和让生成的代码未经审查就成为生产环境修复。

博通引用 1Password 旗下 Off-by-1 Labs 的测试称，在 6,000 个 AI 生成的补丁中，只有 26% 同时修复了漏洞且没有破坏应用功能。3 博通还表示，其工程师在五个月内使用了超过 120 亿个前沿模型令牌分析 Spring，但每一个建议修复方案都经过人工审核。3

因此，博通强调的工作模式可以概括为：

AI 辅助维护，人工批准修复。

模型可以帮助工程师检查庞大的依赖图，找出可能受漏洞影响的路径，并提出代码修改建议。但兼容性、性能、可利用性、回归风险，以及最终发布制品是否正确，仍需要工程师作出判断。3

AI 生成的分支为何可能带来新问题？

博通认为，快速生成的 AI 分支或分叉项目，可能暂时解决一个漏洞，却在长期维护中埋下隐患。如果该分支缺乏持续维护，就可能逐渐偏离上游，错过后续安全修复，也会让用户难以确认谁对软件制品负责。23

TrueSource 试图采用相反的路径：与项目维护者合作，在适当情况下将修复贡献回上游，验证软件制品的构建方式，并由商业服务方持续提供支持。13

这一区别对企业采购者尤其重要。AI 或许能够缩短调查漏洞和准备补丁所需的时间，但它本身并不能证明软件来源可靠，也不能自动保证兼容性、长期维护责任，或在补丁导致生产故障时明确责任归属。

对企业技术团队意味着什么？

TrueSource 的三部分结构，为不同团队提供了相对清晰的切入点：

• Spring 团队可以通过 Spring Enterprise 获得经过整理的版本和安全支持；
• 平台团队与应用安全团队可以通过 Trusted Artifacts 获取覆盖主要语言生态的经验证软件制品和加固容器镜像；
• 基础设施团队可以通过 Data Services 获得 PostgreSQL、RabbitMQ、MySQL 和 Valkey 的支持版本、部署自动化及安全可见性能力。13

更广泛的看点是，博通正在销售一层围绕开源软件构建的“托管式信任层”。它的主张是，企业需要的不只是源代码访问权，还包括可验证的构建过程、持续参与的维护者、经过测试的修复方案，以及清晰可追责的支持关系。

现有材料没有提供 IDC 分析师 Katie Norton 的直接引述，因此无法核实她对这一策略的具体表述。现有证据能够支持的结论是：在博通此次发布中，AI 被定位为提高维护效率的“倍增器”，而人工工程判断仍是生产环境安全决策的关键控制点。3