3.5 漏洞处理要求 (Annex I 第二部分)
3.5.1 概述
CRA 的 Annex I Part II 定义了 8 项漏洞处理要求，制造商必须在含有数字元素的产品的整个支持期内履行这些要求。Part I 规定了产品本身的安全属性（基本安全要求），而 Part II 则涉及处理漏洞的组织和程序义务。
法律依据
Annex I Part II CRA: 漏洞处理要求。含有数字元素的产品的制造商应遵守以下要求，以在支持期内有效处理产品的漏洞。
3.5.2 No. 1 — 识别和记录漏洞及组件
要求： 制造商应识别和记录产品中包含的漏洞和组件，包括以常用的、机器可读的格式编制软件物料清单 (Software Bill of Materials, SBOM)，至少涵盖产品的顶层依赖项。
BAUER GROUP 的实施：
- 每次发布时以 CycloneDX 格式自动生成 SBOM
- 完整覆盖所有直接和传递依赖项
- 每日 CVE 监控，将所有活跃产品的 SBOM 与 NVD、GitHub Advisory Database 和 OSV 进行比对
- CI/CD 流水线中的多引擎安全扫描（Trivy、Grype、OSV-Scanner）
- Dependabot 自动检测过时或存在漏洞的依赖项
- 所有产品及其组件结构的集中清单
证据： 每次发布的 SBOM (CycloneDX JSON)、CVE 扫描报告、依赖项审计日志、组件清单
3.5.3 No. 2 — 及时处理和修复漏洞
要求： 制造商应及时处理和修复漏洞，包括提供安全更新。在技术可行的情况下，安全更新应与功能更新分开提供。
BAUER GROUP 的实施：
- 基于 SLA 的补丁管理流程，定义了明确的响应时间：
- P0（Critical，正在被积极利用）：24 小时内热修复
- P1（Critical）：48 小时内热修复
- P2（High）：7 天内补丁发布
- P3（Medium）：30 天内次版本发布
- 在发布流程中将安全更新与功能更新分离
- 发布前安全门 (Pre-Release Security Gate)：不发布存在已知 Critical/High CVE 的版本
- 通过 Dependabot 自动更新依赖项并自动创建拉取请求
证据： 带时间戳的补丁日志、带安全修复标签的发布说明、SLA 合规报告
3.5.4 No. 3 — 有效且定期的测试和审查
要求： 制造商应对含有数字元素的产品的安全性进行有效且定期的测试和审查。
「定期」的含义
定期测试并不要求按固定间隔机械地重复一套不变的测试方案。它要求定期审查是否有新的输入——新识别的威胁或新发现的漏洞——需要更新现有测试，并据此执行测试。
| 审查结果 | 后果 |
|---|---|
| 识别出影响测试范围的相关新输入 | 必须设计并在产品上执行新的或修改后的测试，以确保没有漏洞未被处理。这可能包括在产品发生变更而使此类测试变得适宜时重新执行现有测试——例如回归测试。 |
| 未识别出此类新输入 | 无需另行设计测试。 其他漏洞处理义务——包括针对所涉风险处理与修复漏洞——继续并行适用。 |
审查的频率、深度与内容必须与产品的网络安全风险特征、其随时间的演变以及威胁态势相称。
审查本身就是证据
由于该义务是审查测试范围是否仍然充分，因此该审查的记录——包括结论为「无需变更」的审查——就是合规证据。一次未产生新测试的季度审查是合规的；缺失审查则不是。
BAUER GROUP 的实施：
- 自动化测试： 每个 CI/CD 流水线中的 SAST、DAST 和 SCA
- 容器扫描： 在构建时和定时任务中对所有容器镜像进行 Trivy 扫描
- 依赖项扫描： 每日基于 SBOM 的 CVE 扫描
- 定期审查： 每季度对每个产品进行安全审查
- 渗透测试 (Penetration Testing)： 关键产品每年一次，重大修改时补充测试
- 风险评估： 针对每个新漏洞进行特定上下文的风险评估
证据： CI/CD 扫描结果、安全审查记录、渗透测试报告、风险评估报告
3.5.5 No. 4 — 已修复漏洞的公开披露
要求： 安全更新发布后，制造商应公开披露已修复漏洞的信息，包括漏洞描述、允许用户识别受影响产品的信息、影响、严重程度和修复措施。如可用，应分配 CVE 标识符。
BAUER GROUP 的实施：
- 通过 GitHub Security Advisories 发布安全通告 (Security Advisories)
- 每个已修复的漏洞包括：
- CVE ID： 通过 GitHub CNA 或 MITRE 分配
- 描述： 对漏洞和受影响版本的清晰说明
- 严重程度： CVSS v3.1/v4.0 评分和等级
- 受影响的产品： 精确的版本信息
- 修复措施： 引用安全更新和建议操作
- 发布说明包含专门的安全部分
- 按照披露策略进行协调披露 (Coordinated Disclosure)
证据： GitHub Security Advisories、发布说明、NVD/OSV 中的 CVE 条目
3.5.6 No. 5 — 协调漏洞披露策略
要求： 制造商应制定并执行协调漏洞披露策略 (Coordinated Vulnerability Disclosure Policy)。
BAUER GROUP 的实施：
- 符合 ISO/IEC 29147:2018 的全面披露策略
- 定义的报告渠道：
- GitHub Security Advisories（首选）
- 专用电子邮件地址 (security@bauer-group.com)
- 每个仓库中的 SECURITY.md
- 对收到的报告有约束力的响应时间（48 小时内初始回复）
- 协调披露期（默认 90 天）
- 安全港条款 (Safe Harbor)，保护善意的安全研究人员
- 致谢计划（安全名人堂 / Security Hall of Fame）
证据： 披露策略（已发布）、仓库中的 SECURITY.md、报告追踪日志
3.5.7 No. 6 — 促进漏洞信息共享
要求： 制造商应采取措施促进其产品及产品中包含的第三方组件的潜在漏洞信息共享，包括提供用于报告漏洞的联系地址。
BAUER GROUP 的实施：
- 联系点： 每个产品和仓库中的专用安全联系地址
- 上游沟通： 主动向上游维护者报告所使用的开源组件中的漏洞
- ENISA 报告流程： 按照报告流程向 ENISA 结构化报告正在被积极利用的漏洞
- 内部沟通： 通过定义的渠道共享安全相关信息（沟通计划）
- 行业合作： 参与相关的信息共享计划（ISAC、安全社区）
证据： 联系点文档、上游报告日志、ENISA 报告、沟通记录
Art. 13(6) 项下上游报告义务的范围与界限见 3.5.11。
3.5.8 No. 7 — 安全分发更新的机制
要求： 制造商应提供机制以安全分发含有数字元素的产品的更新，确保及时部署。安全补丁和更新应通过可信渠道分发。
BAUER GROUP 的实施：
- 签名制品： 所有发布制品均使用 Cosign 签名（签名）
- 可信渠道：
- 容器镜像通过签名的注册表 (GHCR)
- 二进制文件通过签名的 GitHub Releases
- 固件更新通过安全的 OTA 渠道
- 完整性验证： 使用 Cosign verify 的验证流程
- 更新机制： 自动和手动更新路径已记录（更新机制）
- 可用性： 通过冗余基础设施交付更新
- 回滚： 更新失败时可回退到先前版本
证据： 签名日志、更新架构文档、验证指南、回滚测试记录
3.5.9 No. 8 — 及时且免费提供安全补丁
要求： 制造商应确保安全补丁及时且免费发放，并附带通告消息，向用户提供相关信息，包括可能需要采取的操作。
BAUER GROUP 的实施：
- 免费： 在整个支持期内所有安全补丁均免费提供
- 及时： 按照补丁管理的 SLA 要求
- 通告消息： 每个安全更新都附带以下信息：
- 已修复漏洞的描述
- 严重程度 (CVSS 评分)
- 受影响的版本和升级路径
- 建议用户操作（临时方案、配置变更）
- 修复时间表（如有延迟）
- 通知： 主动通知用户可用的安全更新
- 不捆绑： 安全更新不包含强制性的功能变更
重要提示
根据 Art. 13(8) CRA，安全补丁必须在整个支持期内免费提供。将安全补丁与付费维护合同绑定是不允许的。
证据： 带安全部分的发布说明、通告消息、下载统计、用户通知日志
3.5.10 已知可利用漏洞（附件 I 第一部分）
附件 I 第一部分要求，在 Art. 13(2) 风险评估的基础上并在适用情形下，含数字元素的产品在市场上提供时不得存在已知可利用漏洞。虽属第一部分的要求，但它与漏洞处理密不可分，故在此记录。
法律依据
Art. 3(41) CRA： 「『可利用漏洞』指在实际运行条件下具有被攻击者有效利用之潜力的漏洞。」
「可利用」—— 实际条件筛选
并非所有漏洞都可被利用。有些只能在理论条件下被利用——实验室或仿真环境中——或在产品运行环境中不会出现的条件下。这些不触发该要求。
何时算作「已知」？
CRA 未界定该时点。指南给出三条路径：
| 路径 | 说明 |
|---|---|
| 公共数据库 | 该漏洞已列于相关的公开可访问漏洞数据库——例如依 (EU) 2022/2555 指令 Art. 12(2) 建立的欧洲漏洞数据库，或其他知名数据库 |
| 非公开信息 | 安全研究人员的协调披露，或制造商自身的内部测试与分析——明确包括使用 AI 驱动的服务 |
| 重要媒体报道 | 在可靠媒体上被公开且显著地报道，包括网络安全专业出版物或大众媒体 |
报告不等于确认
漏洞被报告或被发现，本身并不意味着它在实践中可被利用或适用于具体产品。制造商必须调查并确认该信息的真实性及其对自有产品的适用性。因此，从首次报告到确认之间可能经过一段有限的时间——与报告义务一样，重点在于迅速行动。
发布决策
该义务适用于投放市场之时（Art. 13(1)）。实践中，潜在可利用漏洞有时在开发周期的最后阶段、即产品进入分销链之前不久才被发现。
由于这是一项风险导向的义务，应由制造商判断该产品能否安全地投放市场，或该漏洞是否必须先行修复。
| 支持发布前修复的因素 | 可能支持发布的因素 |
|---|---|
| 漏洞的严重程度 | 该版本同时修复了其他可利用漏洞 |
| 在实际运行条件下的可利用性 | 该版本为关键系统的持续运行所必需 |
| 潜在影响 | |
| 产品投入使用后所产生的风险 |
该决策必须被记录
带着已知漏洞发布，是一项有记录的风险决策，而非疏漏。须记录所权衡的因素、风险评估的结论以及计划中的补救措施。产品一经投放市场，制造商仍完全受附件 I 第二部分义务的约束。
3.5.11 向上游报告与共享安全修复 (Art. 13(6))
Art. 13(6) CRA 要求制造商 (i) 将集成组件中的漏洞报告给制造或维护该组件的主体，并 (ii) 共享其为修复该漏洞所开发的软件修改。
报告义务的范围
| 规则 | 说明 |
|---|---|
| 版本范围 | 仅就所集成的组件版本报告 |
| 使用维护者的渠道 | 若维护者已设立安全政策、协调漏洞披露流程或指定的报告渠道，则应据此报告——尤其是在过早披露未修补漏洞可能加剧网络安全风险的情形下 |
| 避免重复报告 | 若制造商能够确认维护者已知悉该漏洞，则无需向上游报告。建议其事先查阅公开可访问的漏洞数据库、项目专属安全公告与既有 issue 跟踪器——此举明确旨在减轻上游维护者的负担，尤其是在开源项目中 |
| 仅限组件自身的漏洞 | 仅报告存在于集成组件本身的漏洞——不包括因该组件与制造商自有代码的集成、或因集成其他组件而产生的漏洞 |
| 无人维护的组件 | 若该组件已无维护者，或制造商已不再依赖原维护者提供新版本或安全修复，则无需报告 |
两件建议而非强制的事
- 若某组件的集成揭示了在孤立状态下不明显的行为、交互或安全相关特征，应将其告知维护者。这不是组件漏洞，但能提升组件生态的整体安全性。
- 若某组件已无人维护，应通过合理的替代途径告知其用户——既有的社区机制（邮件列表、issue 工单）或公开的漏洞记录。
共享安全修复
| 规则 | 说明 |
|---|---|
| 格式 | 在适当情形下以机器可读格式提供该修复，便于维护者验证并在适当时集成 |
| 许可（FOSS 组件） | 以与该组件许可证兼容的方式共享修复——例如采用相同许可证，或采用允许维护者以其自有许可证分发该修复的许可证 |
| 维护者的指引 | 若维护者对安全修复的共享方式有指引，则应遵循 |
不被要求的事项
义务是提供，而非贯彻
- 制造商无须确保其修复被维护者接受。
- 制造商无须确保修复被并入组件仓库——维护者可能倾向于其他解决方案。
- 反过来，制造商无须接受维护者提出的修复，可以用其他适当方式缓解问题。
- 若维护者已经提供了修复，而制造商采用了不同的缓解策略——例如在系统其他位置进行配置更改——CRA 不要求将该更改共享至上游。在有助于维护者时，鼓励这样做。
3.5.12 合规矩阵
| 编号 | 要求 | 实施状态 | 证据位置 | 参考 |
|---|---|---|---|---|
| 1 | 识别漏洞和组件 (SBOM) | ✅ | SBOM 归档、CVE 报告 | SBOM、CVE 监控 |
| 2 | 及时修复漏洞 | ✅ | 补丁日志、发布说明 | 补丁管理 |
| 3 | 有效且定期的测试 | ✅ | CI/CD 报告、渗透测试结果 | CVE 监控 |
| 4 | 公开披露（CVE ID、严重程度） | ✅ | GitHub Advisories、NVD | 披露策略 |
| 5 | 协调漏洞披露策略 | ✅ | 披露策略、SECURITY.md | 披露策略 |
| 6 | 促进漏洞信息共享 | ✅ | 联系点、ENISA 报告 | ENISA 报告 |
| 7 | 安全分发更新 | ✅ | 签名日志、更新架构 | 更新机制、签名 |
| 8 | 及时且免费提供补丁 | ✅ | 发布说明、通告 | 补丁管理 |
3.5.4、3.5.10 与 3.5.11 节解释的来源与法律地位：欧盟委员会 CRA 指南。