为了提高效率和节省时间，开发人员通常会利用第三方代码来构建自己的应用程序。然而，这种对外部组件的依赖，尤其是开源软件（OSS），带来了巨大的风险，包括漏洞和许可问题。根据2023 年 GitHub 的一项调查，31% 的开发人员认为查找和修复安全漏洞是他们第二重要的任务，仅次于编写代码（32%）。
因此，许多组织担心他们对开放源码软件的依赖性，因为开放源码软件经常成为黑客攻击的目标。在最近备受瞩目的攻击事件发生后，各组织面临着整个软件供应链的脆弱性增加以及如何有效降低风险的挑战。
ESG的一份研究报告显示，91% 的企业在过去 12 个月中经历过软件供应链事件。最常见的事件包括
Log4J、Curl、Apache Struts 和 OpenSSL 等著名漏洞都曾多次导致运营受损。这些都凸显了当软件供应链中的一个弱点被利用时对组织造成的严重影响。为了应对这些日益增长的风险，世界各地的监管机构都在强调软件的透明度和安全性。采用 软件 Bill of Materials (SBOM)正成为管理软件供应链风险的关键策略。
SBOM 法规势头强劲
SBOM 法规日益普及。许多国家的政府都发布了有关 SBOM 实施的建议。在美国，SBOM 建议已被纳入多份政府指南，其中包括
在欧洲，欧盟网络安全局（ENISA）发布了《物联网Supply Chain 安全指南》，为企业提高网络安全和管理软件相关供应链风险提供了宝贵的见解。
其他国家也发布了类似的指导方针，包括
PCI DSS 如何要求生成 SBOM
支付卡行业数据安全标准（PCI DSS）认识到支付卡数据面临的风险不断增加，因此成为采用 SBOM 的推动力。最新版本的 PCI DSS 4.0 规定必须使用 SBOM，强调了 SBOM 在保护敏感信息方面的关键作用。通过提供详细的软件组件清单，SBOM 使企业能够主动识别和解决漏洞，降低代价高昂的数据泄露和经济损失风险。
PCI DSS 于 2004 年制定，是一项全面的安全标准，旨在保护信用卡信息。它根据每年处理的交易量，对处理信用卡交易的企业提出了一系列严格的要求。2022 年发布的 PCI DSS v4.0 引入了重大变化，包括 SBOM 授权，以应对不断变化的威胁。到 2024 年 4 月，必须遵守 PCI DSS v4.0，具体要求在 2025 年 3 月 31 日前分阶段实施。
通过规定 SBOM，PCI DSS 使企业能够全面了解其软件生态系统，从而主动识别和解决漏洞。这种方法大大降低了代价高昂的数据泄露和经济损失的风险。
PCI DSS 的更新版本4.0.1 于 2024 年年中发布。这意味着之前的 4.0 版本在 2024 年 12 月 31 日之后将不再有效。不过，新版本并没有增加或删除任何规则，也没有更改截止日期。因此，本博客中有关 SBOM 要求的信息适用于 4.0 和 4.0.1 两个版本。
符合 PCI DSS 要求 6.3.2
PCI DSS v4.0 中的 SBOM 要求是 PCI DSS 最新版本中更广泛增强功能的一部分。作为 4.0 版新增的 64 项要求的一部分，SBOM 要求专门针对企业维护软件组件库存的需求，尤其侧重于定制和自定义软件。
这项要求被归入 PCI DSS 第 6 项要求，即通过实施强有力的安全措施以及定期进行漏洞评估和更新，创建并维护安全的系统和应用程序。这项要求对于降低软件漏洞带来的风险和保护持卡人数据至关重要。第 6 节包括五个主要方面：
- 6.1 明确并理解开发和维护安全系统与软件的流程和机制。
- 6.2 以安全的方式开发定制软件。
- 6.3 发现并解决安全漏洞。
- 6.4 面向公众的网络应用程序受到保护，免受攻击。
- 6.5 安全管理所有系统组件的更改。
更具体地说，第 6.3.2 项要求是一项重要的更新，它源于几起第三方组件漏洞或第三方组件提供商漏洞导致持卡人数据泄露的事件。要求内容如下
6.3.2.b 检查软件文档，包括集成第三方软件组件的定制软件文档，并将其与清单进行比较，以核实清单是否包括定制软件和第三方软件组件。
各组织必须彻底记录和管理其应用程序中使用的特定组件和服务。虽然数据流图可能已经涵盖了其中的一些信息，但新的要求要求更详细的文档。随着组件的更新和更改，跟踪这些细节可能会很有挑战性。建议使用标准模板来获取这些信息。此外，一些源代码库（如 GIT）可能会提供导出使用中的组件列表的工具。您的清单至少应包括
- 应用程序组件（通常是存储库项目）
- 第三方组件清单
- 应用程序依赖项（如 Tomcat、Jboss、.NET、中间件）列表
- 授权支付页面脚本列表
OPSWAT SBOM 如何帮助满足 PCI DSS 要求
越来越多的法规要求使用 SBOM 来确保软件供应链的安全。然而，企业却很难建立准确的软件代码组成清单。
资料来源2024 年 EGS 报告
然而，创建准确而全面的 SBOM 给企业带来了巨大的挑战。这些文档要求对软件组件进行细致的清点，必须提供有关其来源、版本和相互依赖关系的详细信息。没有精确的 SBOM，企业就难以有效地识别、评估和降低软件供应链中固有的风险。
生成 SBOM 的指导原则
OPSWAT SBOM 可自动生成代码和容器的 SBOM，从而提高安全性，并有助于软件供应链的合规性。
- 识别所有组件和依赖关系
准确识别所有软件组件（包括开源和第三方库）及其版本和依赖关系。这构成了稳健的 SBOM 的基础。 - 评估开放源码软件风险
评估与开放源码软件组件相关的潜在风险。考虑许可证合规性、安全漏洞和维护状态等因素。根据组件对软件的重要性确定其优先级。 - 扫描开放源码软件漏洞
利用漏洞扫描和 SBOM 生成工具识别开放源码软件组件中的已知漏洞。根据漏洞的严重程度和对软件的潜在影响，确定漏洞的优先级。
使用OPSWAT SBOM
OPSWAT SBOM 可自动生成代码和容器的 SBOM，从而提高安全性，并有助于软件供应链的合规性。
以下是如何利用OPSWAT SBOM 有效生成 SBOM 的方法：
OPSWAT SBOM 支持 10 多种编程语言，包括 Java、JavaScript、Go、PHP 和 Python。这种广泛的支持可确保在各种软件开发生态系统中实现全面的vulnerability detection 。
违规处罚
不遵守 PCI DSS 标准（包括 SBOM 要求）的组织可能会受到每月 5,000 美元到 100,000 美元不等的罚款。如果合规问题一直得不到解决，这些罚款可能会随着时间的推移而增加。
除经济处罚外，不遵守 PCI DSS 还可能导致重大的法律和运营挑战。法律后果可能包括诉讼、辩护费用和巨额赔偿。此外，不遵守规定可能会引发联邦贸易委员会（FTC）等机构的联邦审计，从而导致额外的处罚。
PCI DSS 4.0 合规性的下一步工作
将 SBOM 纳入 PCI DSS 4.0 框架标志着向更安全的软件供应链的关键转变。通过利用OPSWAT SBOM 等先进工具，企业可以有效管理开源风险、提高合规性并防止代价高昂的数据泄露。
利用 SBOM 不再是一种选择，而是一种必要。通过采取积极主动的措施来了解和解决软件依赖性问题，企业可以建立一个强大的安全基础，从而保障其运营并建立客户信任。
