联系电话:
021-68580866
-
博客
希望我们能与您分享和探讨成长中的点点滴滴
如何生成完整的软件物料清单（SBOM）？
创提信息
2025/08/18
分享到
提取供应商软件物料清单（Software Bill of Materials, 简称：SBOM），合并并导出符合 NTIA 标准的SBOM，以便您可以轻松满足监管安全要求。
采用 SBOM 增强许可证合规性和应用程序安全性
软件物料清单 (SBOM) 的核心是一份全面的、机器可读的清单，详细列出了应用程序、系统或软件堆栈中的软件组件。SBOM 类似于传统制造业的物料清单，它提供了软件供应链的透明度和可视性，有助于实现稳健的软件治理和风险管理实践。
SBOM 中应包含哪些组件？
就像食物会列出其成分一样，SBOM 也应该列出软件中的所有第三方和专有组件。套用美国国家电信和信息管理局 (NTIA) 的文档《构建软件组件透明度：建立通用软件物料清单 (SBOM)》中的一句话：
为了表示完整的物料清单，为消费者的软件资产管理和漏洞管理提供足够的透明度，SBOM 必须列举供应商产品中包含的第三方软件依赖项（开源和专有），以及运行时所需的已安装依赖项。
例如，如果供应商下载管理器与供应商的应用程序一起安装软件驱动程序、库或运行时依赖项，则该产品的完整 SBOM 将包括编译二进制文件中的第三方依赖项以及下载管理器安装的软件。
简而言之，如果供应商产品在消费者系统上安装了第三方依赖项，无论是作为产品的组成部分还是作为已安装的启用功能，都应在 SBOM 中列举，以便为软件资产管理和漏洞管理提供必要的透明度。
换句话说，当开发团队选择一个软件组件纳入其应用程序时，SBOM 就应该开始了。这些组件可以是公开可用的开源软件 (OSS)、第三方商用现货 (COTS) 库、内部共享的通用代码模块等等。每个包含的组件都是正在开发软件的 SBOM 的一个元素。所有元素的集合构成了完整的 SBOM。
关于组件的哪些信息是必需的？
与最小权限原则类似，您的 SBOM 应该包含能够帮助接收者回答其所需问题的信息，而非更多。这主要取决于您的 SBOM 的目标受众，但也取决于接收者的监管（政府或行业）要求。
作为基础，您的 SBOM 应包含 NTIA 定义的 SBOM 的最少要素。您还应考虑法规和行业要求，例如 FDA 要求添加其它要素，包括商业组件的支持级别、支持结束日期和已知的安全漏洞。
再次强调，请再次关注结果。您或您的客户（任何需要使用和执行您的 SBOM 的人）需要遵守哪些政府或行业法规？
SBOM 并非万能
假设您在 SaaS 和本地部署模式下提供相同的应用程序。核心应用程序、第三方组件以及支持 SaaS 环境的仪表（备份、可观察性、性能管理）之间有哪些区别？如果您只生成一个 SBOM，那么第二类中的信息将与本地部署模式下运行的应用程序无关。
这是 SBOM 制作中比较棘手的环节之一。在选择要放入 SBOM 的组件时，务必考虑其目标对象。在这种情况下，您同时生产 SaaS 和本地版本的软件——内部团队的 SBOM 和客户的 SBOM 怎么会有所不同呢？
SaaS 应用程序的供应链涵盖整个堆栈，而不仅仅是本地版本所需的应用程序本身。在这种情况下，您最终可能会生成两个 SBOM：
1、一份是On-Prem 版本的 SBOM，在客户接管的安装程序包被提交后生成。此 SBOM 仅包含安装程序包中的内容——On-Prem 应用程序及其依赖项。
2、第二个SBOM 适用于任何针对候选发布版本、标签或分支的构建。它是第一个 SBOM 的超集，并添加了支持 SaaS 版本的附加组件。
为什么要生成两个 SBOM？不妨这样想：您可以将 1 号 SBOM 用于面向客户的工件，将 2 号 SBOM 用于推动安全性和 SOC-2 合规性。此方法可让开发团队和安全团队全面了解风险，简化客户安全审查，并帮助确定持续安全改进的优先级。
FossID生成 SBOM
生成完整的软件物料清单 (SBOM) 并非难事。FossID工具可帮助审计人员生成 SPDX、 CycloneDX和 SPDX Lite 格式的 SBOM，其中详细列出所扫描应用程序中的第三方专有组件、商业组件和开源组件。
1. 摄取 SBOM
第一步是准备要扫描的代码库。SBOM 中最终包含哪些信息很大程度上取决于您的目标受众——您的 SBOM 面向外部受众还是内部受众？您是为本地部署的软件还是同一软件的 SaaS 版本生成 SBOM？
2. 扫描并编码
FossID Workbench中，首先创建一个项目，然后为该项目创建一个扫描。根据您的应用程序存储库结构，项目通常代表单个组件、服务或整个应用程序，而扫描则代表分支或发布版本。
3. 识别开源组件
在此步骤中，您将代码库中的托管和非托管开源组件添加到软件物料清单中。扫描完成后，您将检查FossID在您的代码库中找到的与FossID知识库中收集的开源组件的匹配情况。
4. 识别专有和商业组件
一旦识别出所有开源组件，请查看“无匹配”选项卡中的文件，以与开源组件相同的方式识别任何商业或专有组件。
5. 生成 SBOM 报告
识别所有组件后，请查看“已识别”选项卡以查看组成 SBOM 的组件列表，并确认您已准备好导出 SBOM。
6. 微调组件和许可证数据
根据接收 SBOM 的受众的要求，您可以选择包含或省略有关您的组件及其许可证的某些信息。
7. 逐步扫描最新的 SBOM
拥有第一个 SBOM 后，您可能需要持续生成同一代码库的 SBOM。通常，一个 SBOM 与单个软件版本相关联，并且每个新发布的代码版本都需要一个新的 SBOM。
在 CI/CD 中自动扫描
DevOps 团队可以通过自动化交付流水线中的第 2 步，帮助审计人员始终掌握代码的最新状态。通常，重新扫描的频率取决于您的软件是分版本发布还是持续发布。
将供应商的 SBOM 整合到您的 SBOM 中
锁定软件的 SBOM 后，您现在可以集成软件供应商提供的 SBOM，以生成合并的 SBOM。SBOM 可以导入 Workbench。
关键要点
有效实施 SBOM 可能颇具挑战性，但巧妙运用 SBOM 可以加速风险管理工作流程，而非减慢其速度。最终，SBOM 是一款可以帮助您改善安全态势、提高开发和发布速度，并简化合规流程和客户安全审查的工具。
对于任何希望实现DevSecOps并确保其软件供应链弹性的团队来说，这绝非易事。但FossID可以凭借其技术、专业知识以及经验丰富的经验，为您提供帮助。
欢迎联系我们了解更多资料或申请试用