SBOM大解密：欧盟CRA合规的关键拼图与开源软件陷阱
- 台北讯
-
在上一篇文章中，我们厘清了欧盟《网络韧性法案》（Cyber Resilience Act；CRA）的管辖范围，破解了「硬件不联网就没事」的迷思，并了解到只要硬件绑定云端服务，同样难逃这次CRA法规的天罗地网。今天，我们将目光转向研发内部，深入探讨CRA实作阶段中，最让台湾RD团队与法务主管头痛的技术文件：SBOM（Software Bill of Materials；软件物料清单）。
您可以将SBOM想像成食品包装背后的「成分营养标示」。如果一家食品厂不知道自己的产品里加了什麽原料，一旦爆发食安危机，根本无从查起。同样地，如果您的设备不知道使用了哪些「第三方软件或开源模块」，一旦爆发如Log4j 这种核弹级的网安危机，您要如何在CRA规定的24小时内通报义务下，厘清灾情并进行早期的漏洞通报？
在新的EU CRA法规监管框架下，如果贵公司准备的技术文件（Technical Documentation）中没有包含合规要求的top-level SBOM，产品就无法证明符合CE Mark标章要求。这意味着，不合规的产品将被直接拒于欧盟大门之外，面临极高的产品召回费用与罚款风险。
为什麽欧盟CRA强制要求SBOM？，要了解SBOM的重要性，我们必须先看懂欧盟立法的底层逻辑。
1. 法规依据：CRA附件一的强制要求：根据CRA附件一（Annex I）Part 2针对「漏洞处理（Vulnerability handling）」的基本要求，制造商必须识别并记录产品中包含的漏洞与组件，其中明文规定必须「建立并维护机器可读的软件物料清单（SBOM）」。这不再是加分项目，而是必考题。
2. 供应链透明化与尽职调查（Due Diligence）：现代软件开发早就不再是「从零开始自己刻」。研究指出，现代软件产品中有高达70~90%的程序码是由开源软件（Open Source）或第三方组件拼凑而成。CRA要求制造商必须对整合进产品的所有组件行使「尽职调查（Due Diligence）」。当贵公司的产品在欧盟市场遭遇漏洞通报时，贵公司团队必须依靠SBOM快速盘点受影响的范围，并能实时在欧盟的单一通报平台（Single Report Platform；SRP）上做出精准回应。
3. 自动化监控的基石：CRA法规于2026年9月11日后必须通报的两大事件类型，制造商从2026年9月11日起，需透过单一通报平台（SRP）通报两种特定情况：已遭积极利用的漏洞（Actively Exploited Vulnerabilities）： 产品中存在，且有证据显示正被恶意利用的漏洞。严重事件（Severe Incidents）： 对产品安全性（如可用性、真实性、完整性或机密性）产生严重影响的事件。
面对每天成千上万的新增漏洞（CVE），单靠工程师人工比对是不可能完成的任务。一份结构化、可机器读取的SBOM，是企业导入自动化漏洞监控、快速修补（Patch）与网安事件应变的前提。
由于事件发生不分平日假日，制造商同步可从自动化监控的建置过程中建立24/7的网安应变机制，传统「朝九晚五」的IT团队很可能无法满足24小时通报要求，必须建立全年无休的PSIRT (产品安全事件应变团队) 或SOC能力。
台湾制造商最担心的4个SBOM实务痛点
当老板和研发主管第一次听到要交出「软件清单」时，脑中往往会警铃大作。以下我们针对台湾产业界最关心的「软件机密与智财权」问题，一一为您破解迷思：
常见问题01：交出SBOM，不就等于把我们公司辛苦写的「原始码（Source Code）」和商业机密底牌全看光了吗？SBOM列出的是产品所「依赖的组件名称、版本号以及依赖关系」。打个比方，它就像是列出这块面包用了哪一个牌子的面粉、哪一家的酵母，而不是交出您独家的「发酵环境、烘焙秘方与制程」。SBOM不会包含您的核心演算法、商业逻辑或原始码，您的知识产权（IP）依然受到完整保护。
常见问题02：我们用了很多免费的「开源软件」，如果开源模块有漏洞，是开源社群的责任还是我们的责任？免费的最贵，残酷的真相就是，整合后将是您的责任。根据欧盟官方FAQ的厘清，纯粹由非营利组织开发、未进行商业化的开源贡献者可能获得法规豁免。但是，「将该开源软件商业化、整合进您的硬件或系统中，并对外贩售的制造商（也就是您）」，必须承担最终的合规责任。这代表，RD在引入开源软件前必须做好风险评估，不能抱着「出事再说」的心态。
常见问题03：工程师把软件成分用Excel或PDF条列出来，这样符合CRA的SBOM规定吗？不行，CRA的要求中是不接受手写帐本的格式。CRA及相关调和标准（如正在起草的 EN 40000-1-x 系列）强烈要求 SBOM必须是「机器可读（Machine-readable）」的格式。用 Excel 徒手记录不仅容易出错，更无法与漏洞数据库自动对接。目前国际主流且受认可的格式主要有两种：SPDX（由Linux基金会主导，为ISO/IEC 5962国际标准）。CycloneDX（由OWASP主导，专为应用程序安全与供应链分析设计）。建议企业主应考虑导入自动化工具来生成这两种格式的SBOM。
常见问题04：这份SBOM是要公开在官网上让所有人下载吗？黑客不就可以按图索骥来攻击我们？
按法规所述的界线，并不需要完全公开。CRA并不强制要求制造商将SBOM「公开发布」在网络上。法规的要求是，您必须将SBOM纳入内部的技术文件（Technical Documentation）中妥善保存。只有在欧盟市场监管机构（Market Surveillance Authorities）或符合性评估机构（Notified Body）进行稽核与调查时，您才需要提供给他们。它是合规的证明，而非黑客的导览图。
解方导入：用ISA/IEC 62443将SBOM无缝融入开发流程
在台湾，许多产品单位都忽略「正确性」的意义，SBOM是用来了解哪些弱点的相依关系，但是有许多开源或者商业工具并没有办法生成正确的清单，甚至包含一堆无用的「档案」列表，除了造成使用的障碍，也不具备交换的意义。
CRA法规要求的不是「一张静态的清单」，而是一套「持续动态的漏洞管理流程」。 产品上市后长达5年（或预期寿命内），只要爆发新漏洞，贵团队都必须有能力处理，并针对欧盟Single Report Platform上的通报实时回应。实务上，公司内部产品也会有互相引用的状况，应妥善考虑在接收通报时，就做好内部权责单位的协同作业，避免在CVE公告后，有使用到相关组件或产品的开发单位与产线在时限下手忙脚乱。
在这个阶段，ISA/IEC 62443国际标准就是协助您将SBOM真正落地的最强武器。特别是针对开发流程的 ISA/IEC 62443-4-1（安全产品开发生命周期；Secure SDLC）：对接SM（Security Management）章节： 该章节规范了第三方组件与开源软件的采购及安全评估流程。在RD决定引入某个开源套件前，就必须评估其维护活跃度与已知漏洞。
对接 SUM（Security Update Management）章节：该章节规范了如何利用SBOM来监控新发布的CVE 漏洞，并建立一套标准的修补程序（Patch）发布与测试机制。
专家观点：一石二鸟的合规策略
如果您企业的研发流程已经取得了ISA/IEC 62443-4-1认证，这意味着您的Secure SDLC中已经先天包含了「软件物料管理」与「漏洞应变」的核心精神。面对CRA的SBOM要求，您只需要微调自动化工具的产出格式（如输出为SPDX），就能轻松跨越CRA的高墙，这对已经导入标准的厂商来说，简直是「一石二鸟」的绝对优势！
结语与移动呼吁：别让开源盲区成为欧洲市场的绊脚石
SBOM是现代软件供应链信任的基础，更是未来欧盟海关、Single Report Platform稽核，以及B2B客户采购时的必查项目。而从事件通报的角度来看，SBOM与SRP实际上是紧密相连的。为了满足SRP严苛的24小时通报要求，制造商必须依赖精确且自动化的SBOM。
当零时差漏洞爆发时，企业无法再依赖员工们用人工方式翻找程序码；拥有数码化、可自动查询的SBOM是制造商能在数小时内确认「我的产品是否受影响？」、「哪些供应商组件有重大网安漏洞？」并启动通报机制的唯一方法。
请问，贵公司的RD团队，现在还在用人工Excel记录第三方软件吗？您的团队知道如何将SBOM整合进 CI/CD流水线，并建立自动化的漏洞警报机制吗？法规倒数的时钟滴答作响，与其闭门造车，不如让专家团队来协助您。
ISA台湾分会（ISA Taiwan Section）的业界合作平台，可对接研发流程与风险评估的专家团队，同时，我们也强烈建议企业核心人员参与ISA原厂的专业证照培训：Certificate 2（IC33）：风险评估专家 （Cybersecurity Risk Assessment Specialist）、Certificate 3（IC34）：设计专家（Cybersecurity Design Specialist）、IC47：系统／产品制造商与验证评估人员专属课程。
透过系统化的培训，将储备贵公司的开发团队从源头建立符合CRA要求的软件供应链安全管理流程的能力。备战CRA，您不需要单打独斗。立即联络ISA台湾分会进行培训课程谘询。
