6.4 支持与生命周期
6.4.1 法律依据
依据 Art. 13(8) CRA，制造商必须为每个产品确定并公布支持期。在此期间必须提供安全更新。
法律依据
Art. 13(8) CRA： 「在将含数字元素的产品投放市场时，并在预期产品寿命期内或自产品投放市场起五年内（以较短者为准），制造商应确保该产品（含其组件）的漏洞得到有效处理，并符合附件 I 第二部分的基本网络安全要求。」
Art. 13(8) CRA（判断标准）： 制造商在确定支持期时，应特别考虑用户的合理期待、产品的性质（含其预期用途），以及关于含数字元素产品寿命的相关欧盟法律。
Art. 13(19) CRA： 支持期的结束日期——至少精确到月与年——必须在购买时以清晰易懂的方式说明；支持期届满后，在技术上可行的情况下，必须向用户显示提示。
附件 II 第 5 项 CRA： 支持期属于随产品提供的强制性用户信息。
6.4.2 五年是下限，不是默认值
已更正的做法
支持期反映产品的预期使用时长——即产品预计被使用的期间。五年这一数字仅作为兜底保障，确保漏洞在足够长的时间内得到处理。
CRA 鉴于条款 60 表述明确：合理预期使用超过五年的产品，必须相应地拥有更长的支持期。因此，在整个产品组合中一律声明五年是合规缺口，而非安全下限。
方向是双向的：
| 预期使用时长 | 支持期 |
|---|---|
| 长于五年 | 等于预期使用时长 —— 长于五年 |
| 五年或以上 | 至少五年，与预期使用时长相匹配 |
| 可证明短于五年 | 等于预期使用时长 —— 不适用五年下限 |
确定预期使用时长的标准
| 标准 | 来源 |
|---|---|
| 用户的合理期待 | Art. 13(8) —— 明列标准 |
| 产品的性质，含其预期用途 | Art. 13(8) —— 明列标准 |
| 关于产品寿命的相关欧盟法律 | Art. 13(8) —— 明列标准 |
| 其他制造商投放市场的同类功能产品的支持期 | Art. 13(8) —— 补充标准 |
| 运行环境的可获得性 | Art. 13(8) —— 补充标准 |
| 提供核心功能的第三方集成组件的支持期 | Art. 13(8) —— 补充标准 |
| CRA 行政合作组 (ADCO) 与委员会的相关指导 | Art. 13(8) —— 补充标准 |
所有标准的适用均须确保比例性。
各产品类别的支持期
| 产品类别 | 支持期 | 决定因素 | 示例 |
|---|---|---|---|
| 交付客户的软件产品 | 每个投放市场版本 ≥ 5 年 | 用户合理期待；运行环境可获得性 | 本地部署、一体机 |
| 容器镜像 | ≥ 5 年 | 用户合理期待；基础镜像支持 | 基于 Docker 的服务 |
| 库 / 包 | 自投放市场版本起 ≥ 5 年 | 下游集成周期 | NPM 包、NuGet 包 |
| 固件（消费级 IoT） | 5 年或预期设备寿命，取较长者 | 物理耐久性；用户期待 | 基于 ESP32 的设备 |
| 固件（工业级） | 10 年 | 工业控制器的预期使用时长 | STM32、Zephyr RTOS |
记录推导过程，而不只是数字
市场监管机构可以追问为什么选择了某个支持期。产品档案必须记录适用了 Art. 13(8) 的哪些标准、由此得出何种预期使用时长——而不只是最终日期。
关于确定支持期的说明
支持期的确定必须在投放市场前完成，此后不得缩短。随时可以延长；若实际使用时长超出最初估计，建议延长。
6.4.3 迭代式软件：每个版本一个支持期
软件产品通常以迭代方式发布，经实质性修改的版本可能频繁投放市场。支持期须结合这一开发模式来理解。
规则
投放市场的每个经实质性修改的版本，都必须有各自声明的支持期并符合 Art. 13(8)——包括五年下限，除非该版本的预期使用时长可证明更短。
这源于实质性修改构成重新投放市场 → 1.8 实质性修改。
Art. 13(10) 对软件的宽免
Art. 13(10) CRA 提供了灵活性。制造商可以仅就最后投放市场的版本履行附件 I 第二部分第 2 项的漏洞处理要求——即处理并修复漏洞——前提是早期版本的用户：
- 可以免费获取最新版本，且
- 无需为调整其使用原版本的硬件与软件环境而承担额外成本。
「额外成本」的含义
该概念应作务实且合乎比例的解释，并考虑软件维护与运营中正常、可预期的做法。
| 不属于额外成本 —— 合理的运营投入 | 属于额外成本 |
|---|---|
| 人员时间 | 强制购买新硬件 |
| 例行测试 | 更换基础设施 |
| 配置调整 | 运行环境的根本性变更 |
| 为处理生命周期终止组件或已知安全漏洞而必需的底层软件依赖升级 |
早期版本仍然适用的义务
Art. 13(10) 的范围很窄
该宽免仅涵盖附件 I 第二部分第 2 项。制造商仍须遵守：
- 附件 I 第二部分的其他全部漏洞处理要求——包括对所有后续经实质性修改的版本，维持协调漏洞披露政策以及促进潜在漏洞信息共享的措施（鉴于条款 40）；
- Art. 14 的报告义务；
- Art. 13(19)：若停止修复早期版本，应在技术可行的情况下告知尚未升级的用户。
对旧版本的付费支持仍然可行
在用户可无额外成本升级到最新版本的前提下，制造商仍可以选择继续修复早期版本的漏洞——包括以付费或其他商业安排的方式。CRA 并不要求此类早期版本的安全更新必须免费。
具体示例
| 情形 | 结论 |
|---|---|
| 某手机型号以声明的 X 年支持期投放市场。期间制造商发布经实质性修改的操作系统版本，用户可免费安装且无需新硬件。 | 制造商可仅修复该型号最新操作系统版本中的漏洞。其他漏洞处理义务——CVD、信息共享——在整个支持期内继续适用。 |
| 某企业软件产品每隔数月发布一个经实质性修改的版本，各版本均以自身声明的支持期投放市场。升级需要测试与配置调整，但不需要新硬件或基础设施变更。 | 制造商可依 Art. 13(10)，在用户能够升级后停止修复早期版本，同时对所有后续版本继续履行其他要求。 |
6.4.4 实质性修改与支持期
实质性修改属于重新投放市场——但这不会自动重置或延长支持期。
决定性问题
该实质性修改是否影响了最初确定产品预期使用时长的因素？
实质性修改要求依 Art. 13(8) 标准重新评估。它本身并不产生新的支持期。
| 情形 | 效果 |
|---|---|
| 该修改未影响这些因素 | Art. 13(8) 标准仍指向相同的预期使用时长。修改后产品的支持期与最初确定的剩余预期使用时长一致——即便该剩余时长现已不足五年。 |
| 该修改影响了这些因素 | 制造商依新的预期使用时长重新计算支持期。 |
具体示例
| 情形 | 结论 |
|---|---|
| 某扫地机器人的预期使用时长为 X 年，由硬件的物理耐久性与磨损特性决定。Y 年后，一次构成实质性修改的软件更新增加了新的清扫模式与导航功能。 | 硬件耐久性与用户期待未变 → 无变化；支持期与剩余预期使用时长一致。 |
| 某带云后端（RDPS）的工业机械预期使用时长为 X 年，由硬件耐久性决定。Y 年后，制造商以新的 API 与数据流重构后端——构成实质性修改——但未改变产品性质或用户期待。 | 无变化；支持期与剩余预期使用时长一致。 |
| 某 PLC 的预期使用时长由硬件耐久性决定。数年后，制造商将其嵌入式计算平台——处理器、内存与运行时环境——更换为为显著更长运行寿命而设计的新一代组件。 | 用户期待与产品性质改变 → 标准指向更长的预期使用时长 → 制造商重新计算支持期。 |
维修不触发重新计算
翻新、维护或维修通常不是实质性修改，因此本身不要求重新评估支持期 → 1.8 实质性修改。
6.4.5 生命周期阶段
每个产品经历三个明确的生命周期阶段：
┌──────────────────────────────────────────────────────────────┐
│ 阶段 1：ACTIVE SUPPORT（完整支持） │
│ │
│ 完整支持：功能 + 安全 + 缺陷修复 │
│ 持续时间：直到下一个大版本发布或阶段切换 │
│ SLA：按补丁管理提供安全更新（→ 第 3 章） │
├──────────────────────────────────────────────────────────────┤
│ 阶段 2：SECURITY SUPPORT（仅安全支持） │
│ │
│ 仅安全更新：CRITICAL 与 HIGH 级 CVE │
│ 持续时间：直到支持结束（预期使用时长） │
│ SLA：CRITICAL ≤ 48 小时，HIGH ≤ 7 天 │
├──────────────────────────────────────────────────────────────┤
│ 阶段 3：END OF LIFE（生命周期结束，EOL） │
│ │
│ 不再提供更新 │
│ 提示用户迁移 │
│ 提前 12 个月公告 │
│ 显示 Art. 13(19) 支持结束提示 │
│ SBOM + 签名 + 文档继续归档 │
└──────────────────────────────────────────────────────────────┘阶段之间的切换
| 切换 | 触发条件 | 沟通方式 |
|---|---|---|
| Active → Security | 新的大版本发布 或 管理层决定 | 发布说明 + SECURITY.md 更新 |
| Security → EOL | 支持期届满 | 提前 12 个月公告（见 EOL 流程）+ Art. 13(19) 产品内提示 |
6.4.6 EOL 流程
公告计划
| 时点 | 行动 | 渠道 | 负责人 |
|---|---|---|---|
| EOL 前 12 个月 | 公告 EOL 及计划日期 | GitHub Advisory + 发布说明 + SECURITY.md | 产品负责人 |
| EOL 前 6 个月 | 提醒 + 发布迁移指南 | GitHub Advisory + 文档 | 产品负责人 |
| EOL 前 3 个月 | 最后提醒 + 更新产品页面 | GitHub Advisory + 邮件（已知客户） | 产品负责人 |
| EOL 当日 | 标记最终版本；在技术可行时显示 Art. 13(19) 提示 | 产品内提示 + 发布说明 + SECURITY.md | DevOps 负责人 |
报告义务不随 EOL 结束
附件 I 第二部分的漏洞处理义务适用于支持期内。而 Art. 14 的报告义务在产品不再受支持后继续存在。在生命周期已结束的产品中发现被主动利用的漏洞，仍触发 24 小时 / 72 小时报告义务 → 4.3 ENISA 报告流程。
EOL 之后的义务
即便达到 EOL，依 Art. 13(13) CRA 仍适用以下留存义务：
| 义务 | 期限 | 措施 |
|---|---|---|
| 技术文档归档 | 投放市场后 10 年 | Git 仓库（受保护分支） |
| 所有版本的 SBOM 可获取 | 投放市场后 10 年 | 发布资产 + SBOM 归档 |
| 签名可验证 | 投放市场后 10 年 | Cosign 公钥归档 |
| 既有发布版本可下载 | 投放市场后 10 年 | GitHub Releases / Registry |
| 符合性声明可获取 | 投放市场后 10 年 | Git 仓库 |
历史版本的公开存档
Art. 13(11) CRA 允许提供历史版本的公开软件存档。BAUER GROUP 维护此类存档时，必须以清晰且易于获取的方式告知用户使用不受支持软件的风险。
6.4.7 版本管理策略
BAUER GROUP 采用 Semantic Versioning 2.0.0：
MAJOR.MINOR.PATCH[-PRERELEASE][+BUILD]
MAJOR – 不兼容的 API 变更（新的支持周期）
MINOR – 向后兼容的功能新增
PATCH – 向后兼容的缺陷修复 / 安全更新安全更新始终以 PATCH 版本发布且向后兼容。若为修复漏洞而不可避免地引入破坏性变更，将同时为当前 MAJOR 版本提供替代方案。
版本号不决定是否构成实质性修改
MINOR 版本可能是实质性修改，MAJOR 版本可能不是。语义化版本传达的是 API 兼容性；实质性修改判断关注的是网络安全风险与预期用途。两项判断在每次发布时必须各自独立作出。
6.4.8 产品目录 —— 支持状态
按产品维护
以下产品目录须为 BAUER GROUP 的每个 CRA 相关产品维护。该表在每次大版本发布、阶段切换、实质性修改或 EOL 事件时更新。
负责人： 产品负责人，与安全负责人协同
| 产品 | 类型 | 当前版本 | 支持阶段 | 支持开始 | 支持结束 | 预期使用时长依据 | 下次审查 |
|---|---|---|---|---|---|---|---|
| [填写产品名称] | 软件 | vX.Y.Z | Active Support | YYYY-MM-DD | YYYY-MM-DD | [所适用的 Art. 13(8) 标准] | YYYY-MM-DD |
| [填写产品名称] | 容器 | vX.Y.Z | Security Support | YYYY-MM-DD | YYYY-MM-DD | [所适用的 Art. 13(8) 标准] | YYYY-MM-DD |
| [填写产品名称] | 固件 | vX.Y.Z | Active Support | YYYY-MM-DD | YYYY-MM-DD | [所适用的 Art. 13(8) 标准] | YYYY-MM-DD |
填写说明
CRA 范围内的每个产品（→ 第 1.1 节）都必须在此表中占一行。支持开始对应投放市场日期——对独立软件而言，即该版本首次为分销或使用而供应之日（→ 1.1 适用范围）。支持结束须与预期使用时长一致，且至少为支持开始后五年，除非预期使用时长可证明更短。
6.4.9 用户信息
依 Art. 13(19) 与附件 II 第 5 项 CRA，必须向用户告知支持期。信息须在以下位置提供：
| 信息位置 | 内容 | CRA 义务 |
|---|---|---|
| 购买时 | 支持期结束日期，至少精确到月与年，清晰易懂 | Art. 13(19) |
| 产品文档（投放市场时） | 支持期、支持阶段、EOL 日期 | Art. 13(8)、附件 II 第 5 项 |
| 产品内提示（届满时） | 支持期已结束，技术可行时显示 | Art. 13(19) |
| SECURITY.md（每个仓库） | 受支持的版本、报告渠道 | 附件 I 第二部分 |
| 产品页面 / README | 当前支持阶段、下一次 EOL | 附件 II 第 5 项 |
| 发布说明（阶段切换时） | Active → Security 切换、EOL 公告 | 最佳实践 |
| 用户信息模板 | 完整的安全提示 | 附件 II |
用户信息模板见附录：用户信息。
6.4.10 流程整合
生命周期流程已整合进现有 CI/CD 工作流：
| 事件 | 自动化 | 工作流 |
|---|---|---|
| 新发布 | 生成 SBOM、签名、作为发布资产附加 | cra-release.yml |
| 经实质性修改的发布 | 为该版本声明新的支持期 | 手动 + 目录更新 |
| 大版本发布 | 将前一版本的支持阶段设为 Security Support | 手动 + 目录更新 |
| 达到 EOL | 更新 SECURITY.md、在 Registry 中标记弃用、显示产品内提示 | 手动 + 目录更新 |
| 支持审查（每半年） | 审查产品目录、复核预期使用时长、规划阶段切换 | 手动 |
本页解释的来源与法律地位：欧盟委员会 CRA 指南。