对于计划进入欧盟市场的智能硬件、IoT设备、网络设备、工业控制产品、操作系统和软件产品制造商而言，SBOM（Software Bill of Materials，软件物料清单）是CRA网络安全合规中需要重点关注的内容。
现代数字产品通常集成大量第三方软件、开源组件、软件库和底层依赖。一旦某个组件出现安全漏洞，制造商需要快速判断哪些产品和版本受到影响，并及时采取修复或缓解措施。
欧盟CRA明确要求制造商建立SBOM，以识别和记录产品中的软件组件及相关漏洞。 但企业需要注意，SBOM并不是简单列出几个开源软件名称，也不意味着生成一份清单就完成了CRA合规。
一、CRA是否强制要求SBOM？
是的。
根据《网络弹性法案》Regulation (EU) 2024/2847 附件I第二部分第1项，制造商必须识别并记录具有数字元素的产品中包含的漏洞和组件，其中包括编制采用常用、机器可读格式的软件物料清单，且至少覆盖产品的顶层依赖项。
这意味着，SBOM不是企业可以完全自行决定是否准备的可选材料，而是CRA明确规定的漏洞处理相关要求之一。
需要区分的是，CRA并未在该条款中直接规定所有产品必须使用某一种特定SBOM格式。制造商应结合产品架构、研发工具链及适用的实施要求，选择适当的机器可读格式。
CRA主要产品网络安全要求将于2027年12月11日起全面适用。因此，企业应提前建立SBOM生成、维护和漏洞关联机制，而不是等到全面适用前才开始整理组件清单。
二、CRA要求的SBOM应该包含什么？
CRA明确要求SBOM至少覆盖产品的顶层依赖项，但企业在实际实施中，还应根据产品复杂度和漏洞管理需求，考虑记录更完整的组件信息。
建议重点关注以下内容：
-
组件名称： 软件包、库、框架及第三方组件的名称。
-
版本信息： 当前产品实际使用的组件版本。
-
依赖关系： 产品与直接依赖组件之间的关系，并根据风险需要进一步梳理传递依赖。
-
组件来源： 开源项目、第三方供应商或内部开发模块等来源信息。
-
组件标识： 在适用情况下记录包标识、PURL或其他有助于准确识别组件的信息。
-
漏洞关联信息： 将已知漏洞、受影响版本及处置记录与相应组件关联。
需要注意，以上是便于实施的建议性字段，不代表CRA对所有产品统一规定了完全相同的数据字段。
对于复杂软件产品，如果清单只能列出少量顶层组件，却无法帮助企业定位实际受影响的底层依赖，那么即使已经生成SBOM，也可能难以有效支撑漏洞处理工作。
三、SBOM是不是只需要生成一次？
不是。
SBOM应当反映产品实际包含的软件组件和依赖关系。随着产品版本升级、第三方组件替换、软件库更新或固件变更，原有清单可能不再准确。
例如，一款网络设备的固件使用Linux系统，并集成OpenSSL及其他第三方软件库。如果后续版本升级了其中某个组件，而制造商仍沿用旧版本SBOM，就可能无法准确判断新漏洞影响了哪些产品版本。
因此，建议企业将SBOM管理融入软件构建和版本发布流程：
-
在研发和构建过程中识别软件组件。
-
在产品发布时生成对应版本的SBOM。
-
产品变更后更新组件信息及依赖关系。
-
将SBOM与产品型号、软件版本和发布记录关联。
-
在发现漏洞时，根据组件关系分析受影响产品。
-
保留更新、分析和处置记录。
CRA合规需要的不是一份静态清单，而是能够支持产品漏洞识别与处理的组件信息管理能力。
四、使用开源软件，CRA责任由谁承担？
这是制造商经常关心的问题。
CRA并没有因为软件组件是开源的，就普遍免除制造商在产品层面的网络安全责任。
根据CRA第13条第5款，制造商在集成来自第三方的组件时，需要履行适当的尽职调查，确保这些组件不会损害产品的网络安全。这一要求也涉及并非以商业活动形式投放市场的自由及开源软件组件。
如果制造商发现集成组件存在漏洞，还需要按照CRA第13条第6款向负责制造或维护该组件的个人或实体报告相关漏洞，并按照附件I第二部分规定处理和修复产品中的漏洞。
因此，制造商不能简单地以"漏洞来自开源项目"作为不采取措施的理由。
在实际项目中，企业应建立第三方组件管理机制，包括组件来源识别、版本记录、漏洞监测、风险分析、修复验证和必要的供应商沟通。
五、发现组件漏洞后，制造商应该怎么处理？
SBOM的价值不仅在于记录组件，更在于帮助制造商建立从组件到产品的漏洞处置链路。
假设企业使用的某个开源软件库被披露存在高风险漏洞，制造商应当能够回答：
-
产品哪些版本包含该组件？
-
实际使用的组件版本是否受到影响？
-
该组件是否启用相关功能，漏洞是否影响当前产品？
-
是否需要升级组件、修改代码或采取其他缓解措施？
-
修复后是否需要重新测试？
-
如何记录处置结果并更新相关技术资料？
建议企业建立以下流程：
漏洞信息接收 → 组件与版本匹配 → 影响分析 → 风险判断 → 修复或缓解 → 测试验证 → 记录与更新。
CRA附件I第二部分还要求制造商及时处理和修复漏洞、定期开展有效的安全测试与审查，并提供适当的安全更新。
因此，SBOM应与漏洞管理和产品安全维护机制结合，而不是由研发部门单独生成后就不再维护。
六、SBOM需要公开给所有客户吗？
不能简单地这样理解。
CRA明确要求制造商建立符合规定的SBOM，但不能据此推断所有制造商都必须无条件向所有用户或公众公开完整SBOM。
制造商仍需根据法规规定的具体义务、适用的实施要求、市场监管机构的请求以及相关合同要求，判断SBOM的提供范围和方式。
同时，企业应考虑清单中可能涉及的敏感架构信息、商业信息和其他需要合理保护的内容，在满足适用法规要求的前提下建立适当的访问权限与交付机制。
对于面向客户、评估机构和市场监管机构的不同使用场景，企业可以建立相应的文档版本和证据管理规则，但不能以商业保密为由拒绝履行适用的法定义务。
七、SBOM能否单独证明CRA合规？
不能。
SBOM只是CRA产品漏洞处理要求的一部分，不能替代整体网络安全风险评估、产品安全设计、测试验证、技术文档和符合性评估。
制造商还需要根据CRA附件I要求，落实适用的产品网络安全措施，并按照法规要求形成技术文档及相关证据。
例如，企业即使拥有完整SBOM，如果没有建立漏洞监测和处置机制，无法判断组件漏洞对产品的实际影响，或者不能证明修复措施经过验证，仍然无法仅凭SBOM证明已经满足CRA的相关要求。
更合理的做法，是把SBOM与以下内容关联起来：
-
产品型号、版本和软件构建记录；
-
网络安全风险评估；
-
第三方组件与漏洞管理；
-
安全测试和整改记录；
-
安全更新与支持期管理；
-
CRA技术文档及符合性评估证据。
这样才能形成可持续维护的产品安全证据链。
常见问题
CRA是否要求所有数字产品建立SBOM？
CRA附件I第二部分明确规定制造商应编制覆盖至少顶层依赖项、采用常用机器可读格式的SBOM，并识别和记录产品中的漏洞与组件。
SBOM必须采用SPDX或CycloneDX吗？
CRA该条款没有直接规定所有产品必须使用这两种格式中的某一种。企业应选择符合适用要求、能够支持组件识别和漏洞管理的机器可读格式，并关注后续实施文件。
只有开源软件的产品需要SBOM吗？
SBOM要求并不局限于开源软件。产品中集成的第三方组件、商业软件和其他相关依赖都可能需要纳入组件识别与管理。
有SBOM是不是就满足CRA？
不是。SBOM只是漏洞处理要求的一部分，不能替代风险评估、产品安全设计、漏洞修复、安全更新、技术文档和符合性评估等其他适用义务。