漏洞处理要求 (Annex I Part II)
概述
CRA 的 Annex I Part II 定义了 8 项漏洞处理要求，制造商必须在含有数字元素的产品的整个支持期内履行这些要求。Part I 规定了产品本身的安全属性（基本安全要求），而 Part II 则涉及处理漏洞的组织和程序义务。
法律依据
Annex I Part II CRA: 漏洞处理要求。含有数字元素的产品的制造商应遵守以下要求，以在支持期内有效处理产品的漏洞。
No. 1 — 识别和记录漏洞及组件
要求： 制造商应识别和记录产品中包含的漏洞和组件，包括以常用的、机器可读的格式编制软件物料清单 (Software Bill of Materials, SBOM)，至少涵盖产品的顶层依赖项。
BAUER GROUP 的实施：
- 每次发布时以 CycloneDX 格式自动生成 SBOM
- 完整覆盖所有直接和传递依赖项
- 每日 CVE 监控，将所有活跃产品的 SBOM 与 NVD、GitHub Advisory Database 和 OSV 进行比对
- CI/CD 流水线中的多引擎安全扫描（Trivy、Grype、Snyk）
- Dependabot 自动检测过时或存在漏洞的依赖项
- 所有产品及其组件结构的集中清单
证据： 每次发布的 SBOM (CycloneDX JSON)、CVE 扫描报告、依赖项审计日志、组件清单
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 合规报告
No. 3 — 有效且定期的测试和审查
要求： 制造商应对含有数字元素的产品的安全性进行有效且定期的测试和审查。
BAUER GROUP 的实施：
- 自动化测试： 每个 CI/CD 流水线中的 SAST、DAST 和 SCA
- 容器扫描： 在构建时和定时任务中对所有容器镜像进行 Trivy 扫描
- 依赖项扫描： 每日基于 SBOM 的 CVE 扫描
- 定期审查： 每季度对每个产品进行安全审查
- 渗透测试 (Penetration Testing)： 关键产品每年一次，重大修改时补充测试
- 风险评估： 针对每个新漏洞进行特定上下文的风险评估
证据： CI/CD 扫描结果、安全审查记录、渗透测试报告、风险评估报告
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 条目
No. 5 — 协调漏洞披露策略
要求： 制造商应制定并执行协调漏洞披露策略 (Coordinated Vulnerability Disclosure Policy)。
BAUER GROUP 的实施：
- 符合 ISO/IEC 29147:2018 的全面披露策略
- 定义的报告渠道：
- GitHub Security Advisories（首选）
- 专用电子邮件地址 (security@bauergroup.com)
- 每个仓库中的 SECURITY.md
- 对收到的报告有约束力的响应时间（48 小时内初始回复）
- 协调披露期（默认 90 天）
- 安全港条款 (Safe Harbor)，保护善意的安全研究人员
- 致谢计划（安全名人堂 / Security Hall of Fame）
证据： 披露策略（已发布）、仓库中的 SECURITY.md、报告追踪日志
No. 6 — 促进漏洞信息共享
要求： 制造商应采取措施促进其产品及产品中包含的第三方组件的潜在漏洞信息共享，包括提供用于报告漏洞的联系地址。
BAUER GROUP 的实施：
- 联系点： 每个产品和仓库中的专用安全联系地址
- 上游沟通： 主动向上游维护者报告所使用的开源组件中的漏洞
- ENISA 报告流程： 按照报告流程向 ENISA 结构化报告正在被积极利用的漏洞
- 内部沟通： 通过定义的渠道共享安全相关信息（沟通计划）
- 行业合作： 参与相关的信息共享计划（ISAC、安全社区）
证据： 联系点文档、上游报告日志、ENISA 报告、沟通记录
No. 7 — 安全分发更新的机制
要求： 制造商应提供机制以安全分发含有数字元素的产品的更新，确保及时部署。安全补丁和更新应通过可信渠道分发。
BAUER GROUP 的实施：
- 签名制品： 所有发布制品均使用 Cosign 签名（签名）
- 可信渠道：
- 容器镜像通过签名的注册表 (GHCR)
- 二进制文件通过签名的 GitHub Releases
- 固件更新通过安全的 OTA 渠道
- 完整性验证： 使用 Cosign verify 的验证流程
- 更新机制： 自动和手动更新路径已记录（更新机制）
- 可用性： 通过冗余基础设施交付更新
- 回滚： 更新失败时可回退到先前版本
证据： 签名日志、更新架构文档、验证指南、回滚测试记录
No. 8 — 及时且免费提供安全补丁
要求： 制造商应确保安全补丁及时且免费发放，并附带通告消息，向用户提供相关信息，包括可能需要采取的操作。
BAUER GROUP 的实施：
- 免费： 在整个支持期内所有安全补丁均免费提供
- 及时： 按照补丁管理的 SLA 要求
- 通告消息： 每个安全更新都附带以下信息：
- 已修复漏洞的描述
- 严重程度 (CVSS 评分)
- 受影响的版本和升级路径
- 建议用户操作（临时方案、配置变更）
- 修复时间表（如有延迟）
- 通知： 主动通知用户可用的安全更新
- 不捆绑： 安全更新不包含强制性的功能变更
重要提示
根据 Art. 10(16) CRA，安全补丁必须在整个支持期内免费提供。将安全补丁与付费维护合同绑定是不允许的。
证据： 带安全部分的发布说明、通告消息、下载统计、用户通知日志
合规矩阵
| 编号 | 要求 | 实施状态 | 证据位置 | 参考 |
|---|---|---|---|---|
| 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 | 及时且免费提供补丁 | ✅ | 发布说明、通告 | 补丁管理 |