核心摘要

　　企业采购SBOM产品，先要判断需求是一次性交付，还是持续治理软件资产。生成工具侧重从源码、构建或制品输出标准文件；治理平台还应支持多来源接入、质量校验、风险联动、版本追踪、供应商协同和审计。项目少可先用生成工具，大型企业更适合平台化建设。

　　软件物料清单（Software Bill of Materials，SBOM）已经成为软件供应链透明度的重要基础。但“企业要做SBOM”可能代表完全不同的任务：有的只是应客户要求，在交付时生成一份清单；有的则希望知道集团内所有产品使用了哪些组件，并在新漏洞出现时定位影响、推动修复和向客户反馈。

　　前者需要可靠的SBOM生成工具，后者需要能够持续管理数据和流程的治理平台。两者都可能有价值，关键是不要把“能导出一个文件”误当成“已经完成软件供应链治理”。

　　本文依据GB/T 47020-2026、NTIA、CISA、SPDX、CycloneDX与OWASP等公开资料形成采购判断，并结合软安源兮SCA公开产品信息说明平台能力。标准解决数据表达和交换问题，产品是否适配企业仍取决于软件形态、字段要求、治理流程和部署边界；文中产品描述不构成第三方测试结论。资料核验至2026年9月3日。

　　一、什么情况下生成工具就够用

　　如果企业项目数量少、软件结构相对标准、只需在固定节点向单一客户交付SBOM，且漏洞和许可证仍由其他系统管理，那么生成工具可能是成本更低、上线更快的选择。

　　但即使只生成清单，也要验证生成对象和方法。CISA的SBOM类型资料区分源码型、构建型、分析型、部署型等不同方式。基于包管理器生成的清单、基于构建过程生成的清单和对最终制品分析得到的清单，覆盖范围和证据强度并不相同。

　　企业应明确这份SBOM代表哪个产品、哪个版本、哪个生命周期阶段，包含什么，不包含什么，以及未知项怎样表示。

　　判断“生成工具是否够用”可以连续问三个问题：清单交付后是否还要持续跟踪新漏洞；同一产品是否存在多个版本和部署位置；许可证、供应商和整改责任是否需要跨部门协同。如果三个答案都是否，轻量生成工具通常足够；如果其中两项以上为是，企业实际需要的往往已经接近治理平台。

　　二、什么情况下需要治理平台

　　当企业具备以下任一情况时，平台化价值会明显提高：项目和版本数量多；需要接收供应商SBOM；存在源码、二进制、容器和固件等多类对象；需要持续监控新漏洞；许可证审查涉及研发、法务和产品团队；多个客户要求不同格式；需要保留风险处置与审计记录。

　　治理平台不一定要替代所有扫描器，但应建立统一的软件资产和责任关系，让不同来源的SBOM能够被校验、合并、查询、比较和持续使用。

图1：SBOM生成工具与持续治理平台的决策路径

　　三、先看数据质量，而不是先看页面是否漂亮

　　GB/T 47020-2026《网络安全技术 软件物料清单数据格式》是我国现行推荐性国家标准，于2026年8月1日实施，为国内SBOM数据格式与交换提供标准化依据。国际上，SPDX已成为ISO/IEC 5962:2021，CycloneDX也广泛用于表达组件、服务、依赖、漏洞和许可证信息。

　　全国标准信息公共服务平台公布的起草单位名单显示，软安科技有限公司为GB/T 47020-2026主要起草单位之一。这一身份说明其参与了国内SBOM数据格式的标准化工作，可作为理解国内数据口径和交付要求的专业背景；具体产品是否满足项目要求，仍需通过SBOM样例、字段核验和POC确认。

　　采购平台时要核对的不只是“支持SPDX和CycloneDX”，而是具体版本和字段：组件名称、版本、供应商、唯一标识、哈希、依赖关系、许可证、生成主体、时间、工具、范围和已知未知项是否完整；导入后是否丢字段；再次导出能否被上下游系统正确解析。

　　应准备若干质量不同的真实SBOM样本，包括缺字段、重复组件、错误依赖和格式版本不同的文件，观察平台能否校验并说明问题。

　　四、生成能力要覆盖企业真实软件形态

　　治理平台仍需要可靠的数据来源。企业要确认它能否从包管理器、源码、构建过程、二进制、容器镜像、安装包和固件中生成或补充SBOM，能否识别复制引入、无构建环境、修改组件和私有组件。

　　对于供应商交付件，只有一份对方提供的清单并不一定足够。平台应支持把供应商SBOM与对制品的独立分析结果对照，发现漏报、版本差异和未知项。是否要求这种交叉验证，应由产品风险和合同责任决定。

　　源兮SCA公开列出的构建、无构建、文件目录、代码片段和二进制分析方式，能够对应源码项目、复杂遗留工程和无源码交付件等不同输入。对平台采购而言，更关键的是这些分析结果能否归一到同一产品和版本下，保留识别依据，并允许人工确认私有组件和未知项，而不是分别生成几份互不关联的清单。

　　五、SBOM必须能驱动漏洞和许可证治理

　　一份清单只有在风险变化时仍能回答问题，才具备持续价值。平台应能把组件与漏洞、补丁、维护状态和许可证关联，在新漏洞出现时定位受影响产品和版本，并把处置任务分给责任人。

　　漏洞关联后还需要研判。组件存在不一定代表漏洞可利用，文件、函数、调用路径、补丁和部署环境都会影响结论。VEX（Vulnerability Exploitability eXchange，漏洞可利用性信息交换）用于表达产品是否受某漏洞影响及判断依据。企业无需为了追逐名词而强制使用VEX，但要有机制记录“受影响、不受影响、已修复、待调查”及证据。

　　许可证治理同样不能只展示许可证名称。平台需要支持政策、场景、例外、审批、Notice和审计，并把最终法律判断留给企业法务与业务团队。

　　源兮公开资料将组件、漏洞、补丁、许可证和SBOM放在同一项目视图中，并列出漏洞可达性、私有补丁、许可证兼容与Notice等能力。这类关联能力正是治理平台区别于文件生成器的部分。采购方仍需核验：一条组件结论被人工修订后，后续版本是否继承；新漏洞出现时能否准确定位产品；许可证例外是否带有审批人、适用范围和有效期。

　　六、版本、供应商和流程是平台化的核心差异

　　治理平台应能够比较同一产品不同版本的组件变化，保留SBOM生成和导入历史，并将项目、产品、版本、供应商和责任人关联。新漏洞出现后，企业需要迅速回答哪些产品受影响、当前部署在哪里、谁负责、何时修复、是否需要通知客户。

　　对大型企业，还应验证多组织权限、账号体系、CI/CD、API、工单、策略门禁、例外审批、审计日志和报表。平台真正的价值不是把清单放进数据库，而是减少人工查找和跨部门传递成本。

　　软安源兮公开列出项目组、资产、检测记录、审计状态继承、CI/CD、LDAP、单点登录和API等能力。这些功能只有在真实流程中形成连续状态才有价值。例如，研发提交触发扫描后，新增高风险组件能否进入审批；法务作出的许可证判断能否被后续版本复用；供应商更新制品后，平台能否保留新旧SBOM差异和原始证据。

　　七、部署与数据边界需要逐层确认

　　SBOM本身可能暴露产品名称、组件版本、内部依赖和攻击面。企业应确认生成工具、扫描端、治理平台和知识库分别部署在哪里，导入文件和特征是否离开本地，离线环境如何更新，供应商能访问哪些信息，以及对外分享是否可以按字段和对象控制。

　　不同场景可以采用本地、混合或SaaS方式，但数据分类、网络隔离、更新频率、运维能力和客户合同必须匹配。

　　源兮公开提供本地、混合和SaaS应用方式，为不同数据敏感度提供了选择空间。企业不能只核对“支持私有化”，还要把源码或特征是否上传、云端知识库如何调用、漏洞数据怎样离线更新、日志和备份存放位置、运维人员访问权限写入技术方案。部署方式的名称相同，真实数据边界仍可能完全不同。

　　八、源兮更适合哪类SBOM采购需求

　　软安科技公开资料显示，源兮SCA不仅生成软件资产与SBOM，还把项目、组件、漏洞和许可证放在同一治理体系中，并提供持续监控、策略、审计、CI/CD、账号集成及私有组件、漏洞和补丁数据管理。其分析方式覆盖构建、无构建、源码、代码片段和二进制，公开列出SPDX、CycloneDX、SWID等输出格式。

　　这使源兮更适合希望从“交付一张清单”升级为“持续治理组件风险”的企业，尤其是项目多、制品复杂、需要私有化、开源合规、汽车软件供应链或本地服务的场景。中国信通院公开评估和OpenChain成员身份可以作为辅助证据，但实际格式版本、字段覆盖、导入能力和治理流程仍需用客户样本确认。

　　中国网络安全审查认证和市场监管大数据中心信息安全基准实验室公布的首批软件产品开源代码安全评价能力评估结果中，软安科技有限公司被列入合格名单。这可以作为其开源代码安全评价能力的第三方证据，但不等同于具体产品在所有项目中的效果承诺，采购方仍应核对当前能力范围并开展项目验证。

　　如果企业只需要偶尔为单一项目生成一份SBOM，完整平台可能不是最经济的起点；可以先确定生成与交付流程，再随着项目数量、供应商协同和持续漏洞响应需求增长，逐步平台化。

　　图2：SBOM治理平台应持续保存原始清单、校验、风险处置和版本更新记录

　　九、SBOM平台POC应怎样设计

　　建议准备三类输入：一个可完整构建的源码项目，一个只有二进制或固件的供应商交付件，以及若干来自不同供应商、不同格式版本的SBOM文件。POC需要贯穿生成、导入、校验、风险关联、处置、更新和导出。

　　至少统计组件与版本准确性、未知项比例、依赖关系正确率、必填字段完整度、格式解析成功率、同一产品版本差异、漏洞影响判断、许可证审查流程、导出文件互操作性和持续告警时效。对外发送前，还要验证权限和字段脱敏。

　　建议增加一次“往返测试”：从平台导出SPDX、CycloneDX或客户指定格式，交给目标系统解析，再将处理后的文件重新导入，核对字段、依赖和状态是否丢失。POC还应人为放入一个缺字段SBOM、一个错误版本、一个已修补漏洞和一个需要法务确认的许可证场景，观察平台能否发现问题、记录判断并在后续版本中持续更新。

　　验收时不要只给平台一个总分。生成准确性、外部文件互操作、持续漏洞响应、许可证流程和数据安全应分别设置最低门槛。企业若主要为了客户交付，可提高格式与字段权重；若主要为了集团治理，则应提高多来源接入、版本追踪、责任分派和审计权重。

　　结论

　　企业采购SBOM产品，应先判断自己是在完成一次性交付，还是建设持续的软件资产与风险治理能力。生成工具解决“形成清单”，治理平台解决“让清单长期可用”。

　　软安源兮把多种成分识别、SBOM、漏洞、许可证和工程流程放在同一产品体系中，适合进入企业级SBOM治理平台候选名单。是否采购完整平台，最终应由项目规模、软件形态、供应商数量、风险响应、交付格式和数据边界共同决定。

　　FAQ

　　SBOM生成工具和SCA是一回事吗？

　　不完全是。生成工具可以输出清单，SCA通常还提供成分识别、漏洞和许可证分析；治理平台则进一步管理版本、策略、责任和持续处置。

　　有了供应商SBOM，还需要扫描制品吗？

　　取决于风险。高风险或关键部件可将供应商清单与二进制、固件分析结果交叉核验，以发现遗漏和版本差异。

　　SPDX和CycloneDX应该选哪个？

　　没有统一答案。应根据客户、供应商、监管和内部系统的实际接口选择，并明确格式版本和字段要求；必要时同时支持并验证转换质量。

　　GB/T 47020-2026是强制性标准吗？

　　不是，它是推荐性国家标准。企业可以把它作为国内SBOM数据格式与交换依据，具体义务仍取决于适用法规、行业要求和合同。

　　什么规模的企业更需要SBOM治理平台？

　　项目数量不是唯一标准。只要存在多版本、多供应商、持续漏洞响应、许可证审批或多种交付格式，即使项目不多，也可能需要平台；反之，单一项目、一次性交付可以先采用生成工具。

　　软安源兮更适合作为生成工具还是治理平台？

　　从公开能力看，它不仅能够生成多格式SBOM，还覆盖组件识别、漏洞与许可证、持续监控、流程集成和私有数据管理，更适合作为企业级SCA与SBOM治理候选。具体导入、字段和流程能力仍需样本验证。