Published On
2026年09月23日
Read Time
20分钟
CRA 重构了开源软件的选型逻辑
多年来，工业自动化领域在 Qt Community Edition 与 Commercial Qt 之间的抉择，一直被视为前期成本与便利性之间的取舍。欧盟《网络弹性法案》（CRA）从根本上改变了这一选型逻辑。
2027 年 12 月 11 日之后在欧盟市场投放 PDE 的制造商，必须通过证据、文档与可审计流程 证明技术栈中每一个组件均满足 CRA 的网络安全基本要求 —— 包括 GUI 框架在内。
任何在欧盟市场投放 PDE 的制造商 —— 无论其产品产地何处 ——均须承担全部合规义务。
本文将深入分析 CRA 的实际要求、Qt Community Edition 能够覆盖与无法覆盖的范围，以及 Commercial Qt 如何填补这一差距。
缩略语列表
CE 标志（CE marking）— 欧洲合格认证标志 — 制造商声明符合相关欧盟法规的合规声明
CNA — CVE 编号机构（CVE Numbering Authority）
CRA — 欧盟《网络弹性法案》，法规（EU）2024/2847
CVE — 通用漏洞披露（Common Vulnerabilities and Exposures）
ES — 延伸支持（Qt 商业服务）
ESM — 延伸安全维护（Qt 商业服务）
GPL — GNU 通用公共许可证
GUI — 图形用户界面
IEC — 国际电工委员会（如 IEC 61508、IEC 62443）
LGPL — GNU 宽通用公共许可证
LTS — 长周期支持版本
PDE — 含数字元素产品（CRA 术语）
PLC — 可编程逻辑控制器
SBOM — 软件物料清单
SCADA — 数据采集与监控系统
TLS — 传输层安全协议
24h/72h/14d 事件报告指南 — 在发现正被积极利用的漏洞后须在 24 小时内发出早期预警、72 小时内提交完整通报，并在补救措施可用后 14 天内完成最终报告的义务
CRA 设定的合规门槛
根据 CRA，任何在欧盟市场投放 PDE 的制造商 —— 无论产品产地何处 —— 均须承担全部义务。基本要求（CRA 附录 I）主要包括：
-
贯穿产品全生命周期的默认安全设计 —— 交付时不存在已知可利用漏洞、采用安全默认配置、防止未经授权的访问，以及保障存储、传输和处理数据的机密性与完整性。
-
CRA 第 14 条规定的漏洞处理义务 —— 在发现正被积极利用的漏洞后，须在 24 小时内向相关 CSIRT 及 ENISA 发出早期预警，72 小时内提交完整通报，并在补救措施可用后 14 天内完成最终报告（24h/72h/14d 事件报告指南）。
-
在产品支持期内（默认为五年）免费提供安全更新。
-
SBOM 须覆盖所有第三方组件，包括开源依赖项。
-
对第三方组件履行尽职调查，明确涵盖免费开源组件。
-
编制技术文档（CRA 附录 VII）以证明合规性；合规评估通过后，制造商方可签发欧盟合规声明并加贴 CE 标志。
报告时限从制造商获知漏洞正被积极利用时开始计算，而非从制造商决定采取行动时起算。第三方组件的合规责任由最终产品制造商承担。若某工业 HMI 使用了 Qt，而 Qt 中发现了严重漏洞，则无论该制造商使用的是 Qt Community Edition 还是 Commercial Qt，均须自行应对。
第三方组件的合规责任由最终产品制造商承担。
Qt Community Edition 的适用范围与局限
Qt Community Edition 以 LGPL 授权分发大多数模块，少量模块采用 GPL 授权。对于处于原型开发阶段的团队、纯内部工具（不向欧盟市场投放）、无商业分发性质的研究或教育项目，Qt Community Edition 是合理的选择。
然而在 CRA 框架下，Qt Community Edition 的三项结构性特征演变为实质性制约。
-
Qt Project 作为开源治理机构，预计不会以 CRA 意义上的制造商身份运作。这意味着，在商业产品中使用 Qt Community Edition 的工业制造商无法从 Qt Project 继承 CRA 合规性 —— 全部制造商义务须由最终产品制造商独立承担。
在商业产品中使用 Qt Community Edition 的制造商，无法从 Qt Project 继承 CRA 合规性。
-
Qt Community Edition 的安全更新节奏与 CRA 要求错位。Qt Community Edition 在下一次次版本（Minor）发布前（约六个月内）可获取维护版本。此后，安全补丁虽仍向 Qt Community Edition 用户开放，但相较于 Commercial Qt 客户存在 12 个月的延迟。因此，Qt Community Edition 用户面临三种选择：
-
每六个月跟进每一次新次版本发布（并每次重新进行产品验证）；
-
接受补丁修复披露与其进入开源渠道之间长达 12 个月的延迟；或
-
从最新商业维护版本中手动移植补丁（这既需要合法获取相关补丁的权限，也需要具备安全执行此操作的内部工程能力）。
依赖 Qt Community Edition 的长寿命工业产品制造商，在结构上无法满足 24h/72h/14d 事件报告要求 —— 除非升级框架版本（并重新认证产品），或在内部维持补丁移植能力。
在 CRA 框架下，这 12 个月的延迟是决定性问题。CRA 第 14 条强制要求遵守 24h/72h/14d 事件报告时限。依赖 Qt Community Edition 的长寿命工业产品制造商，在结构上无法满足这一时限要求 —— 除非升级框架版本（并重新认证产品），或在内部维持补丁移植能力。相比之下，Commercial Qt LTS 自 Qt 6.8 起在五年窗口期内即时交付维护版本和安全补丁，并提供超出该窗口期的延伸选项。
-
-
Qt Community Edition 用户须自行负责对完整依赖关系图中的通用漏洞披露（CVE）进行跟踪管理，并处理所有 LGPL/GPL 分发义务（源代码可用性、许可证声明、书面要约）—— 这些均须叠加在其 CRA 文档合规工作之上。
Commercial Qt 如何填补差距
Qt Group 针对 Commercial Qt 的产品体系专门围绕 CRA 的全生命周期要求进行了架构设计，以下几项内容与工业自动化制造商直接相关：
-
五年 LTS 维护窗口，安全补丁即时交付。自 Qt 6.8 起，Commercial Qt LTS 版本至少维护五年，维护版本与安全补丁在整个维护期内即时发布。制造商可在产品 CRA 支持期内保持使用单一 Qt 版本而无需触发重新认证，且安全补丁的发布时效满足 CRA 规定的 24h/72h 报告时限要求。
-
Qt Group 就其自有组件承担制造商角色。Commercial Qt 客户可获取 Qt Group 的 CRA 合规工作成果——包括 SBOM、漏洞处理流程、安全开发生命周期证明材料 —— 作为其自身合规文档的输入。
-
Qt Group 是 CVE 编号机构（CNA）。Qt 内的安全问题由 Qt Group 分配 CVE 标识符，并通过有据可查的处理流程进行跟踪管理；Commercial Qt 客户可在 48 个工作小时内收到响应（高级支持 用户为 24 小时）。
-
Qt Group 对 Qt 自有第三方组件履行尽职调查义务。Qt Group 对 Qt 内部的第三方及开源组件实施符合 CRA 要求的尽职调查，从而减轻下游制造商须独立核查的工作量。
对于受监管环境下的工业自动化产品，五年 LTS 窗口有时并不充分。工厂控制器、流程工厂中的 HMI，或任何已通过 IEC 61508、IEC 62443 或行业特定安全标准认证的设备，无法简单地升级 Qt 版本 —— 框架变更通常意味着产品须重新经历重新认证或重新鉴定流程，而这往往超出制造商在监管时间表内的承受能力。为此，Qt Group 提供超出标准五年 LTS 窗口的延伸安全维护（ESM）与延伸支持（ES），在产品服役期间对固定 Qt 版本持续提供安全补丁。对于受认证约束而锁定在特定 Qt 版本的制造商，这是在 CRA 全生命周期安全更新义务与框架无法迁移的现实之间取得平衡的切实可行的路径。
对于受认证约束而锁定在特定 Qt 版本的制造商，LTS、ES 与 ESM 是在 CRA 全生命周期安全更新义务与框架无法迁移的现实之间取得平衡的切实可行的路径。
随着 IEC 62443 在工业自动化领域的普及，GUI 框架被纳入安全相关或认证相关技术栈已日益成为常态。在这种情形下，SBOM、漏洞处理记录、CVE 分配以及第三方尽职调查输出并非可选的便利项，而是公告机构、客户采购团队或市场监管机构必然要求查阅的合规材料。
此外，这些材料还具有双重价值：IEC 62443-4-1 与 IEC 62443-4-2 要求的证明材料在结构上与 CRA 附录 I 高度相似，因此 Qt Group 为 CRA 合规产出的制造商级文档可直接复用于 62443 合规档案，无需从头构建。
CRA 框架下 Qt Community Edition 与 Commercial Qt 对比
|
CRA 义务领域 |
Qt Community Edition（LGPL/GPL） |
Commercial Qt |
|
安全更新 |
维护版本发布至下一次次版本发布（约 6 个月）；此后，补丁较 Commercial Qt 渠道延迟 12 个月，或需手动移植 |
自 Qt 6.8 起，在五年 LTS 窗口内即时交付维护版本与安全补丁；Commercial Qt 次版本维护期 12 个月；可申请 ESM / ES 延伸支持 |
|
漏洞处理支持 |
通过 security@qt-project.org 走社区流程；无响应时限承诺 |
早期预警列表；客户支持响应时限 48 个工作小时（高级支持为 24 小时） |
|
第三方组件尽职调查 |
用户须对所有传递性依赖独立自行开展 |
由 Qt Group 针对 Qt 自有组件开展；调查成果作为输入直接提供给制造商 |
|
CRA 合规文档 |
用户基于开源工件自行编制 |
Qt Group 的制造商级文档可作为客户合规档案的输入材料直接使用 |
|
源代码与许可声明分发 |
每件交付产品都有完全的 LGPL / GPL 义务 |
无 LGPL / GPL 源代码披露义务；可依据 Qt 框架协议（FA）获取专有源代码访问权 |
|
认证相关附加组件 |
不适用 |
Qt Safe Renderer、Application Manager、Axivion、Coco 及 Squish 均可在商业条款下获取 |
规律一以贯之：Qt Community Edition 在制造商具备足够内部能力、可自行承担 GUI 框架层全部 CRA 合规负担的情况下仍是可行之选。Commercial Qt 则将这一负担的相当大一部分转移至 Qt Group，并以合同保障和有据可查的服务级别为支撑。
对工业自动化工程团队的实际影响
对于正在应对 CRA 合规过渡的工业自动化制造商，以下三点值得重点关注。
第一，关于 Qt 许可方式的讨论往往启动过晚，且参与讨论的利益相关方有失偏颇。GUI 与应用开发团队通常以技术维度评估框架——性能、控件库、工具链——这些固然重要，但并非决定许可选型是否带来 CRA 合规风险的关键维度。网络安全、法务、质量以及产品合规等职能部门需要在架构决策阶段就参与进来，而非等到采购流程末尾。
SBOM、漏洞处理记录、CVE 分配以及第三方尽职调查输出并非可选的便利项。
第二，CRA 将制造商的产品视为一个整体。即便是使用 Commercial Qt 的制造商，仍须对完整技术栈承担合规责任。Qt Group 的配套质量保障产品组合 ——Axivion（静态代码分析与架构验证）、Coco（代码覆盖率分析）、Squish（GUI 自动化测试）——旨在为制造商提供针对其自有代码（而非仅限于 Qt 部分）满足网络安全基本要求所需的证据基础。结合 Qt Application Manager 的沙箱隔离能力，以及 Qt 框架默认启用 TLS 和 X.509 证书的安全基线，Commercial Qt 技术栈提供了一条从安全设计到漏洞处理与上报的完整有据可查的路径。
Qt Group 的质量保障产品组合旨在为制造商提供其自有代码满足网络安全基本要求所需的证据，而不仅限于 Qt 部分。
第三，Qt Community Edition 的“免费”始终伴随着隐性成本 —— 体现在内部补丁维护、合规工作以及 LTS 版本管理上。在 CRA 框架下，这些隐性成本将转化为可审计的法定义务 ，违规将面临监管后果。根据 CRA 第 64 条，对基本要求的严重违反，罚款最高可达 1500 万欧元或前一财年全球年营业额的 2.5%（以较高者为准）；其他义务违反适用较低档次的处罚。
Qt Community Edition 的“免费”始终伴随着隐性成本 —— 体现在内部补丁维护、合规工作以及 LTS 版本管理上。
Qt Group 的建议
预计在 2027 年 12 月 11 日之后向欧盟市场投放产品的工业自动化制造商，至少应将当前的 Qt 使用情况与“CRA 框架下 Qt Community Edition 与 Commercial Qt 对比”表中列出的各项 CRA 义务领域进行逐一对照梳理。
若存在差距 —— 通常集中于 SBOM、漏洞处理以及跨生命周期安全更新等领域 —— 则需在内部自行弥补与通过 Commercial Qt 及 Qt Group 配套产品组合获取支持之间做出抉择。
CRA 并非凭空创造了工业自动化领域使用 Commercial Qt 的理由，但它确实让这一理由变得可量化、可审计和可执行。
对于产品将在 2028 年仍然在售于欧盟市场的制造商而言，启动这场对话的时机就是现在。