架构

BAUER GROUP 的 CRA 自动化分布在两个仓库中：

• CRA 专用工作流和操作位于 SEC-CRACompliance（本仓库）
• 通用操作（VEX 生成、SBOM 认证）位于 automation-templates

消费者仓库（您的产品）只需一行 uses: 即可调用 CRA 发布工作流。

可复用工作流

cra-release.yml — 发布制品

主要工作流。为每次发布生成、签名和存档所有 CRA 制品。

使用方法（零配置）：

jobs:
  cra:
    uses: bauer-group/SEC-CRACompliance/.github/workflows/cra-release.yml@main
    permissions:
      contents: write
      id-token: write
      attestations: write
      security-events: write

流水线流程：

cra-scan.yml — 定期漏洞扫描

用于持续 CVE 监控（Art. 10(8)）。通过 cron 计划每日运行。

cra-report.yml — Hub API 报告

将合规数据发送到软件安全中心 API 进行集中跟踪。

完整的消费者工作流

最小配置（零配置）

# .github/workflows/cra.yml
name: CRA Compliance

on:
  release:
    types: [published]
  schedule:
    - cron: '0 6 * * 1'
  workflow_dispatch:

permissions:
  contents: write
  id-token: write
  attestations: write
  security-events: write
  issues: write

jobs:
  cra-release:
    if: github.event_name == 'release'
    uses: bauer-group/SEC-CRACompliance/.github/workflows/cra-release.yml@main
    permissions:
      contents: write
      id-token: write
      attestations: write
      security-events: write

  cra-scan:
    if: github.event_name == 'schedule' || github.event_name == 'workflow_dispatch'
    uses: bauer-group/SEC-CRACompliance/.github/workflows/cra-scan.yml@main
    permissions:
      contents: read
      security-events: write
      issues: write

完整配置（所有参数）

jobs:
  cra-release:
    if: github.event_name == 'release'
    uses: bauer-group/SEC-CRACompliance/.github/workflows/cra-release.yml@main
    with:
      run-validation: true              # 在生成 CRA 制品前运行验证
      validation-command: 'npm run ci'
      sign-sbom: true                   # Cosign 无密钥签名
      fail-on-critical: true            # CRITICAL CVE 时阻止发布
      enable-grype: true                # 额外的 Grype 扫描
      attest-sbom: true                 # GitHub SBOM 认证
      generate-vex: true                # OpenVEX 文档
      generate-eu-doc: true             # EU 符合性声明 (Annex V)
      render-pdfs: true                 # JSON → PDF 渲染
      classification: 'important-class-1'
      support-period-years: 5
    permissions:
      contents: write
      id-token: write
      attestations: write
      security-events: write

  cra-scan:
    if: github.event_name == 'schedule'
    uses: bauer-group/SEC-CRACompliance/.github/workflows/cra-scan.yml@main
    with:
      severity-threshold: 'MEDIUM'
      create-issue: true
    permissions:
      contents: read
      security-events: write
      issues: write

参数参考

cra-release.yml

所需权限

发布制品

合规评分

8.1.1 工具 -> CRA 合规矩阵

本映射展示了每个工具覆盖了哪些 CRA 要求。

8.1.2 GitHub 生态系统

Dependabot

GitHub Security Advisories

GitHub Actions（自动化模板）

8.1.3 安全扫描

Trivy (Aqua Security)

Grype (Anchore)

OSV-Scanner (Google)

Snyk

Gitleaks + GitGuardian

8.1.4 SBOM 与合规

Syft (Anchore)

FOSSA / 许可证合规 (License Compliance)

8.1.5 签名与完整性

Cosign (Sigstore)

8.1.6 CRA 合规工作流（本仓库）

除了自动化模板之外，本仓库还提供了专用的 CRA 工作流，可在每个源代码仓库中复用。详见 8.2 自动化工作流。

组合操作（CRA 专用）

组合操作（通用，在 automation-templates 中）

可复用工作流

CLI 工具

8.1.7 计划扩展

8.1.8 总结：通过工具实现的 CRA 覆盖

                         CRA 要求
                    ┌─────────────────────────┐
                    │  Art. 10（制造商）        │
                    │  ├── (1) 安全性          │──→ Trivy, Gitleaks, 代码审查
                    │  ├── (2) 风险            │──→ 手动 + 模板
                    │  ├── (4) 第三方          │──→ FOSSA, 许可证合规
                    │  ├── (6) 漏洞            │──→ CVE-Monitor, Dependabot
                    │  ├── (7) 更新            │──→ Dependabot, CI/CD
                    │  ├── (8) 无 CVE          │──→ CVE-Monitor, Trivy
                    │  ├── (9) CVD             │──→ GitHub Advisories
                    │  ├── (12) 完整性         │──→ Cosign + Attestation
                    │  └── (16) 支持           │──→ SECURITY.md
                    ├─────────────────────────┤
                    │  Art. 13（信息）          │
                    │  ├── (6) CVD 政策        │──→ SECURITY.md
                    │  └── (23) SBOM           │──→ Trivy/Syft
                    ├─────────────────────────┤
                    │  Art. 14（报告）          │
                    │  ├── 24小时预警           │──→ ENISA SRP + Teams
                    │  ├── 72小时通知           │──→ ENISA SRP
                    │  └── 用户信息            │──→ GitHub Advisory
                    └─────────────────────────┘

概述

cra-check 是一个零依赖的 Node.js CLI 工具，用于验证产品是否满足 CRA 合规要求。检查合规制品的存在和质量 — SBOM、VEX、漏洞扫描、安全策略和支持期限。

使用方法

# 检查当前目录
npx @bauer-group/cra-check

# 检查 GitHub 仓库（最新发布）
npx @bauer-group/cra-check bauer-group/my-product

# JSON 输出
npx @bauer-group/cra-check --format json

# CI 模式
npx @bauer-group/cra-check --ci --min-score 70

模式

本地模式

扫描文件系统中的 CRA 制品：

远程模式

通过 GitHub API 获取数据 — 发布资产、签名、SECURITY.md。

输出

  CRA Compliance: my-product v2.3.1
  ══════════════════════════════════════════

  SBOM                ✅ PASS  CycloneDX, 142 组件
  SBOM 签名           ✅ PASS  Cosign 签名 + 证书存在
  VEX 文档            ✅ PASS  15 声明 (3 已分类)
  漏洞                ⚠️ WARN  0 关键, 2 高危
  安全策略            ✅ PASS  SECURITY.md 存在
  支持期限            ✅ PASS  5 年

  Score: 85/100 ████████████████░░░░ PASS

CI/CD 集成

- name: 🔍 CRA 合规检查
  run: npx @bauer-group/cra-check --ci --min-score 70
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

退出码

要求

• Node.js >= 20
• 无 npm 依赖

完整映射：CRA 条款 -> 文档 -> 工具

本矩阵将每项相关的 CRA 要求映射到对应的文档和已实施的工具。它是审计和合规性评估 (Conformity Assessment) 的核心参考。

详细映射：8.1 工具映射（工具 -> CRA 要求）

按经济运营者角色划分的义务

按产品类别估算工作量

* I 类：完全采用协调标准时可自评；否则需第三方评估。

Art. 10 -- 制造商义务 (Obligations of Manufacturers)

Art. 13 -- 信息义务 (Information Obligations)

Art. 14 -- 报告义务 (Reporting Obligations)

Art. 16 -- 授权代表 (Authorised Representative)

Art. 28 -- 合规声明与 CE (Declaration of Conformity & CE)

Annex I, 第I部分 -- 安全要求 (Security Requirements)

Annex I, 第II部分 -- 漏洞处理 (Vulnerability Handling)

Annex II -- 用户信息 (User Information)

Annex VII -- 技术文档 (Technical Documentation)

图例

7.1.1 概述

根据《网络弹性法案》(Cyber Resilience Act, CRA)，每个含数字元素的产品都必须被归入一个 CRA 风险类别。分类结果决定了所需的合规评估程序。CRA 区分四个类别：标准 (Standard)、Class I（重要）、Class II（重要）和关键 (Critical)。

7.1.2 分类决策树

以下决策树概述了产品分类的系统化方法：

产品是否列于 Annex IV 中？
├── 是 → 关键 (CRITICAL)（需 EUCC）
└── 否
    └── 产品是否列于 Annex III 中？
        ├── 是 → 属于哪个类别？
        │   ├── Class II → CLASS II（Module B+C 或 H）
        │   └── Class I → CLASS I（Module A* 或 B+C）
        └── 否 → 标准 (STANDARD)（Module A）

* Module A 仅在完全适用协调标准时可用

7.1.3 产品类别

类别：标准（默认）

合规评估： 内部控制 (Internal Control)（Module A）— 自我评估

大多数产品属于此类别。制造商自行执行合规评估。

典型产品：

• 标准 Web 应用
• 内部工具和实用程序
• 非关键容器镜像
• 简单 IoT 传感器

Class I（Annex III）

合规评估： 内部控制（Module A）（适用协调标准时）或 EU 型式检验（Module B+C）

Annex III 中的示例：

• 身份管理系统和特权访问管理软件
• 独立浏览器
• 密码管理器
• 搜索、删除和隔离恶意软件的软件
• VPN 产品
• 网络管理系统
• SIEM 系统
• 引导管理器
• 防火墙、IDS/IPS（非工业用途）
• 路由器、调制解调器（用于互联网接入）
• 具有安全相关功能的微控制器
• 操作系统（非服务器/桌面 Class II）

Class II（Annex III）

合规评估： EU 型式检验（Module B+C） 或 全面质量保证（Module H）

Annex III 中的示例：

• 虚拟机管理程序和容器运行时环境
• 工业用途的防火墙和 IDS/IPS
• 防篡改微控制器/微处理器
• 服务器、桌面、移动设备的操作系统
• 公钥基础设施和证书颁发机构
• 工业自动化与控制系统 (IACS)
• 工业 IoT 设备（不受其他行业法规约束的）

类别：关键（Annex IV）

合规评估： 欧洲网络安全证书（EUCC），保证级别为"实质性 (substantial)"或更高

Annex IV 中的示例：

• 硬件安全模块 (HSM)
• 智能卡及类似设备（含安全元件）
• 智能卡读卡器
• 机器人和机器控制器的传感器和执行器
• 智能电表网关

7.1.4 各类别的合规评估

* 仅在适用协调标准或符合 EU 网络安全认证时

7.1.5 BAUER GROUP 的相关产品类型

对照 Annex III（重要产品）审查

对照 Annex IV（关键产品）审查

BAUER GROUP 产品的典型分类

7.1.6 分类流程

对于每个产品，必须执行以下流程：

1. 功能审查

验证产品是否满足 Annex III 或 IV 中列出的功能之一。系统性地与所有类别进行比对。

2. 预期用途

考虑预期用途：

• 产品是否用于关键基础设施？
• 是否处理敏感/个人数据？
• 是否具有网络功能？
• 被入侵是否可能造成物理损害？

3. 记录分类结果

使用风险评估模板记录分类决定。

7.1.7 分类的文档化

每个产品的分类记录在产品描述中：

1. 对照 Annex III 和 IV 审查 — 系统性地与所有类别比对
2. 理由 — 为何适用此分类（引用附录）
3. 合规评估程序 — 适用哪个模块
4. 日期 — 分类执行日期
5. 责任人 — 分类执行人

4.3.1 法律依据

根据 Art. 14 CRA，制造商须向 ENISA 或相关国家 CSIRT 主管机构报告特定安全事件。报告义务自 2026 年 9 月 11 日 起适用。

4.3.2 须报告的事件

被积极利用的漏洞 (Actively Exploited Vulnerability)（Art. 14(1)）

BAUER GROUP 产品中的漏洞正在被积极利用。根据 Art. 3(42) CRA，当有可靠证据表明漏洞已被恶意行为者在未经系统所有者许可的情况下利用时，即构成积极利用。

积极利用的指标：

• 被纳入 KEV 目录（CISA 已知被利用漏洞目录）
• 威胁情报源 (Threat Intelligence Feeds) 报告利用活动
• 客户或安全研究人员的报告 提供利用证据
• 在日志、监控或事件响应流程中 自行检测 到
• 公开报告（厂商公告、博客、论坛）中关于攻击的信息

严重安全事件 (Severe Security Incident)（Art. 14(3)）

严重影响产品或其用户安全的事件（Art. 3(43) CRA）。

归类为严重事件的标准：

4.3.3 角色与职责

4.3.4 报告平台

ENISA 统一报告平台 (Single Reporting Platform, SRP)

自 2026 年 9 月 11 日起，ENISA 统一报告平台作为中央报告入口可用：

欧盟成员国国家 CSIRT

如 ENISA SRP 暂时不可用，通知应提交至相关国家 CSIRT。以下是全部 27 个欧盟成员国的完整目录：

来源：ENISA CSIRTs Network / ENISA CSIRT Inventory。截至：2026-02。首次通知前请核实最新联系方式。

4.3.5 报告流程

第 1 阶段：预警（≤ 24 小时）

负责人： 安全负责人

检测到被积极利用的漏洞/严重事件
    │
    ├── 1. 立即通知
    │   ├── 通知安全负责人（立即，全天候）
    │   └── 创建事件工单（GitHub Issue，标签：incident + enisa）
    │
    ├── 2. 初步评估（≤ 2 小时）
    │   ├── 确认漏洞/事件
    │   ├── 识别受影响的产品和版本
    │   ├── 验证是否存在积极利用（KEV、威胁情报）
    │   ├── 确定严重程度 (CVSS)
    │   └── 确认 ENISA 报告义务
    │
    ├── 3. 提交 ENISA 预警（≤ 24 小时）
    │   ├── 模板：/templates/enisa-early-warning
    │   ├── 平台：ENISA SRP（首选）或 CSIRT（备选）
    │   └── 根据 Art. 14(1) 的最低内容要求：
    │       ├── 制造商身份信息
    │       ├── 受影响产品/受影响版本
    │       ├── 漏洞/事件的性质
    │       ├── 严重程度（CVSS 评分 + 向量）
    │       ├── 确认存在积极利用
    │       ├── 影响的初步评估
    │       └── 计划的紧急措施
    │
    └── 4. 并行措施
        ├── 启动沟通计划（→ 5.4）
        ├── 通知管理层（针对 SEV-1/SEV-2）
        └── 启动紧急措施（临时解决方案、隔离）

证据： 通知确认截图 + 事件工单中的时间戳

第 2 阶段：漏洞通知（≤ 72 小时）

负责人： 安全负责人 + DevOps 负责人

详细评估进行中/已完成
    │
    ├── 1. 深入技术分析
    │   ├── 完成受影响产品的版本列表
    │   ├── 分配 CWE 分类
    │   ├── 计算完整的 CVSS v3.1 向量
    │   ├── 记录攻击向量和前提条件
    │   └── 描述利用场景
    │
    ├── 2. 记录措施
    │   ├── 已采取的缓解措施
    │   ├── 补丁开发状态
    │   ├── 可用的临时解决方案
    │   └── 建议的用户措施
    │
    └── 3. 提交 ENISA 通知（≤ 72 小时）
        ├── 模板：/templates/enisa-notification
        ├── 平台：ENISA SRP
        └── 根据 Art. 14(2) 的最低内容要求：
            ├── 预警参考编号
            ├── 详细的漏洞描述
            ├── CVE-ID（如已分配）
            ├── 所有受影响的产品版本
            ├── CWE 分类 + CVSS 向量
            ├── 技术细节（攻击向量、影响）
            ├── 已采取缓解措施的状态
            ├── 可用的补丁/临时解决方案
            ├── 建议的用户措施
            └── 受影响用户/设备的估计数量

证据： 通知确认 + 事件工单中的完整副本

第 3 阶段：最终报告（≤ 14 天）

负责人： 安全负责人

修复已完成或进展良好
    │
    ├── 1. 准备最终文档
    │   ├── 完成根因分析
    │   ├── 创建完整的事件时间线
    │   ├── 列出所有已采取的措施
    │   ├── 识别已提供的补丁/更新
    │   ├── 评估残余风险
    │   └── 总结经验教训
    │
    └── 2. 提交 ENISA 最终报告（≤ 14 天）
        ├── 模板：/templates/enisa-final-report
        ├── 平台：ENISA SRP
        └── 根据 Art. 14(3) 的最低内容要求：
            ├── 预警和通知的参考编号
            ├── 详细的漏洞描述
            ├── 根因分析
            ├── 完整的事件时间线
            ├── 所有已采取的纠正措施
            ├── 已提供的补丁/更新（含版本号）
            ├── 残余风险及其缓解
            ├── 妥协指标 (IoC)（如有）
            ├── 经验教训
            └── 预防未来事件的措施

证据： 通知确认 + 事件工单中的完整副本 + 归档

4.3.6 用户通知（Art. 14(8)）

在 ENISA 通知的同时，须 立即 通知受影响用户有关漏洞及可用的纠正措施。

4.3.7 文档记录与存档

每份 ENISA 通知均须完整记录。该文档作为面向市场监管机构 (Market Surveillance Authorities) 的 合规证据（Art. 52 CRA）。

每份通知的强制性文档

参考编号方案

所有通知使用统一的参考编号方案：

4.3.8 准备措施（2026 年 9 月 11 日前）

报告义务生效前须完成以下措施：

4.3.9 决策树：报告义务

检测到安全事件
    │
    ├── 我们产品中的漏洞是否受到影响？
    │   ├── 否 → 无 CRA 报告义务（如适用请检查 NIS2）
    │   └── 是 ↓
    │
    ├── 漏洞是否正在被积极利用？
    │   ├── 是 → 须报告 (Art. 14(1))
    │   │         → 24 小时预警 + 72 小时通知 + 14 天最终报告
    │   └── 否 ↓
    │
    ├── 是否属于严重安全事件？
    │   ├── 是 → 须报告 (Art. 14(3))
    │   │         → 24 小时预警 + 72 小时通知 + 14 天最终报告
    │   └── 否 ↓
    │
    └── 常规漏洞处理
        → 漏洞管理（→ 第 3 章）
        → 根据 SLA 进行补丁管理
        → 无 ENISA 报告义务

文档控制

注意： 本文件为公开版本。个人数据（姓名、联系方式）未包含在本版本中，仅在内部版本中提供。

变更历史

约束力

本手册对所有参与含数字元素产品 (Products with Digital Elements) 的开发、运营、分销或支持的 BAUER GROUP 员工具有约束力。偏离本手册所述流程需获得安全负责人和管理层的书面批准。

法规 (EU) 2024/2847 – 网络弹性法案

网络弹性法案 (Cyber Resilience Act, CRA) 是欧盟关于含数字元素产品横向网络安全要求的法规。该法规于2024年11月20日在《欧盟官方公报》上发布（OJ L, 2024/2847），并于2024年12月10日生效。

CRA 在所有欧盟成员国直接适用，对含数字元素产品的制造商 (Manufacturer)、进口商 (Importer) 和分销商 (Distributor) 规定了强制性义务。

法律特征

目的与目标

CRA 追求两个核心目标：

1. 产品安全要求（Annex I 第一部分） – 含数字元素的产品只有在满足基本网络安全要求后才能在欧盟市场上提供。这包括安全设计 (Security-by-Design)、保密性、完整性、可用性以及攻击面的最小化。

2. 漏洞处理（Annex I 第二部分） – 制造商必须在整个支持期内（至少5年，Art. 13(8)）系统地识别、记录、评估、修复漏洞，并向用户和主管机构报告。

与 NIS2 的关联

CRA 补充了 NIS2 指令（指令 (EU) 2022/2555）。NIS2 规范的是关键和重要实体运营方的网络安全，而 CRA 则针对这些实体所使用产品的安全性。CRA 的报告义务（Art. 14）以 NIS2 报告义务（Art. 23 NIS2）为蓝本，并使用相同的 ENISA 报告平台。

适用范围

根据 Art. 2 CRA，本法规适用于其预期用途或合理可预见用途包含与设备或网络的直接或间接逻辑或物理数据连接的含数字元素的产品。

对于 BAUER GROUP，这涉及：

• 软件 – 独立应用程序、微服务、API、容器镜像
• 固件 – 嵌入式系统（ESP32、STM32、Zephyr RTOS）
• 库 – 公开发布的 NPM 和 NuGet 包
• 含软件的硬件 – 物联网设备、工业控制器
• 远程数据处理 – 作为产品组成部分的云组件

详细的产品类别和豁免情况请参见 1.1 适用范围与产品。

本章子页面

本手册结构

本手册按照 CRA 的核心流程进行组织。每章涵盖一个独立的合规领域，包含法律依据、流程描述和操作实施：

工具链

BAUER GROUP 依赖全自动化工具链确保 CRA 合规，无需额外手动操作：

法规参考

术语和定义

使用此决策树确定网络弹性法案 (CRA) 是否适用于您的产品，以及应遵循的合规路径。

决策树

关卡 1：包含数字元素的产品？

┌───────────────────────────────────────────────┐
│ 产品是否包含数字元素？                          │
│ （软件、固件或具有逻辑数据连接的硬件              │
│  — Art. 3(1) CRA）                             │
│                                               │
│   否 → CRA 不适用 → 停止                       │
│   是 ↓                                        │
└───────────────────────────────────────────────┘

"包含数字元素的产品" 是指任何软件或硬件产品及其远程数据处理解决方案，包括单独投放市场的软件或硬件组件（Art. 3(1) CRA）。

关卡 2：豁免条款 (Art. 2(2))

┌───────────────────────────────────────────────┐
│ 是否适用以下任何豁免？                          │
│                                               │
│ ☐ 医疗器械 (Reg. 2017/745, 2017/746)          │
│ ☐ 机动车辆 (Reg. 2019/2144)                   │
│ ☐ 航空 (Reg. 2018/1139)                       │
│ ☐ 船舶设备 (Dir. 2014/90/EU)                  │
│ ☐ 国家安全 / 军事产品                          │
│ ☐ 纯 SaaS（无产品组件）                        │
│                                               │
│   是 → CRA 不适用（行业专项法规适用）→ 停止     │
│   否 ↓                                        │
└───────────────────────────────────────────────┘

关卡 3：开源评估 (Art. 18–19)

┌───────────────────────────────────────────────┐
│ 这是开源软件吗？                               │
│                                               │
│   否 → 继续关卡 4 ↓                           │
│   是 → 是否存在商业活动？                       │
│        （销售、付费支持、付费集成、SaaS 提供）    │
│                                               │
│     否 → CRA 不适用 → 停止                     │
│     是 → 适用开源管理者义务                     │
│          (Art. 18–19) → 继续 ↓               │
└───────────────────────────────────────────────┘

关卡 4：产品分类 (Art. 6–7, Annex III & IV)

┌───────────────────────────────────────────────┐
│ 产品是否列于 Annex IV？                        │
│                                               │
│   是 → 关键产品                                │
│        → 需要 EUCC 认证                        │
│        → 参见：合规评估 / EUCC                  │
│   否 ↓                                        │
├───────────────────────────────────────────────┤
│ 产品是否列于 Annex III？                       │
│                                               │
│   是 → 哪个类别？                              │
│     II 类 → 模块 B+C 或模块 H                  │
│             → 参见：合规评估 / 模块 B+C         │
│     I 类  → 模块 A（含 hEN）或 B+C             │
│             → 参见：合规评估 / 模块 A           │
│   否 ↓                                        │
├───────────────────────────────────────────────┤
│ 标准（默认类别）                               │
│ → 模块 A（自我评估）                           │
│ → 参见：合规评估 / 自我评估                     │
└───────────────────────────────────────────────┘

结果总览

预估合规工作量

* I 类仅在未完全采用协调标准时才需第三方评估。

后续步骤

根据您的分类结果：

1. 记录决策 → 产品分类记录
2. 启动合规流程 → 合规评估概述
3. 准备文档 → 技术文档
4. 建立报告机制 → ENISA 报告流程

1. 产品识别

2. 适用性评估

适用性结果： [ ] CRA 适用 / [ ] CRA 不适用

如不适用，请说明原因：___

3. 产品分类

3.1 Annex IV 检查（关键产品）

Annex IV 结果： [ ] 已列入（→ 关键） / [ ] 未列入（→ 继续）

3.2 Annex III 检查（重要产品）

Annex III 结果： [ ] II 类 / [ ] I 类 / [ ] 未列入（→ 标准）

3.3 分类结果

4. 合规评估路径

5. 审批

概述

事件响应框架 (Incident Response Framework) 涵盖了完整的 CRA 报告义务。自 2026 年 9 月 11 日 起，制造商须向 ENISA 或相关国家主管机构报告被积极利用的漏洞 (Actively Exploited Vulnerability) 和严重安全事件。

报告义务概览

章节结构

1.14.1 概述

网络弹性法案 (CRA) 和 NIS2 指令（指令 (EU) 2022/2555）是互补的欧盟网络安全法规。CRA 规范产品，而 NIS2 涉及运营方（关键和重要实体）。像 BAUER GROUP 这样的公司可能同时受两项法规的约束。

BAUER GROUP 的完整NIS2合规文档请访问 nis2.docs.bauer-group.com。

1.14.2 CRA 与 NIS2 的界定

1.14.3 决策树：适用哪项法规？

BAUER GROUP 是否制造含数字元素的产品？
├── 是 → CRA 适用（作为制造商）
│   └── 产品是否为 SaaS（纯云端）？
│       ├── 是 → CRA 不适用于 SaaS
│       │   └── 检查 NIS2（作为运营方）
│       └── 否 → CRA 适用
└── 否 → CRA 不适用于制造商

BAUER GROUP 是否为关键或重要实体？
├── 是 → NIS2 适用（作为运营方）
│   └── 检查行业（NIS2 Annex I/II）
└── 否 → NIS2 不适用

1.14.4 重叠要求

漏洞管理

协同效应： CRA 合规的漏洞处理在很大程度上也满足 NIS2 Art. 21 第2款 (e) 的要求。

报告义务

CRA 报告流程：ENISA 报告流程

供应链安全

协同效应： CRA 合规的供应链流程也满足 NIS2 Art. 21 第2款 (d) 的供应链要求。

事件响应

差距： NIS2 明确要求业务连续性和危机管理，而 CRA 侧重于产品安全。

1.14.5 综合合规策略

第1步：确定范围

第2步：利用协同效应

以下流程可同时覆盖两项法规：

1. 漏洞管理 → 漏洞管理
2. 事件响应 → 事件响应
3. 供应链安全 → 供应链
4. SBOM 管理 → SBOM 与签名

第3步：NIS2 特定补充

超出 CRA 的 NIS2 要求：

第4步：统一报告流程

对于同时受两项法规约束的公司：

1. 联合初步评估流程用于事件
2. 并行报告给 CRA 和 NIS2 机构（在统一平台可用之前）
3. 统一模板（ENISA 早期预警）
4. 文档化的决策逻辑： 哪个事件触发哪项报告义务

1.14.6 时间表

概述

保障软件供应链安全是 CRA 的核心要求。制造商在集成第三方组件时必须履行尽职调查 (Due Diligence) 义务，并确保整个供应链的完整性。

安全措施

已实施的措施

章节结构

概述

漏洞管理 (Vulnerability Management) 是 CRA 下的核心义务之一。制造商必须在整个支持期内对其产品中的漏洞进行识别、评估、修复和报告。

流程架构

                         +---------------------+
                         |  SBOM（每次发布）     |
                         +----------+----------+
                                    |
              +----------+----------+----------+----------+
              v          v          v          v          v
    +--------------+ +--------+ +--------+ +--------+ +--------+
    |CVE 监控      | |Dependa-| | Trivy  | |  OSV-  | | Grype  |
    |（每日 SBOM） | |  bot   | | 扫描   | |Scanner | |（可选）|
    |              | |（PR）  | |（CI/CD）| |（CI/CD）| |        |
    +------+-------+ +---+----+ +---+----+ +---+----+ +---+----+
           |             |          |          |          |
           +-------------+----------+----------+----------+
                                    v
                         +----------------------+
                         |  分诊与评估           |
                         |  (CVSS / 严重程度)    |
                         +----------+-----------+
                                    |
                   +----------------+----------------+
                   v                v                 v
         +-----------------+ +--------------+ +--------------+
         |  严重/高危       | |  中等/低危    | |  无 CVE      |
         |  -> 立即修补     | |  -> 计划修复  | |  -> 继续监控  |
         |  -> 如需向       | |  -> 下一次    | |              |
         |     ENISA 报告   | |    发布       | |              |
         +-----------------+ +--------------+ +--------------+

章节结构

职责

9.1.1 目的

CRA 合规声明是产品所有 CRA 合规制品的公开摘要。它作为客户、市场监督当局和内部审计的中心参考点。

9.1.2 生成原则

                    ┌──────────────────────────┐
                    │  .compliance/             │
                    │  cra-statement.json       │
                    │  (唯一事实来源)             │
                    └─────────┬────────────────┘
                              │
          ┌───────────────────┼───────────────────┐
          │                   │                   │
          ▼                   ▼                   ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ 合规页面        │ │ CE 标志         │ │ 容器标签        │
│ (HTML/PDF)      │ │ (关于对话框、   │ │ (OCI 注解、     │
│ 门户上          │ │  README、页脚)  │ │  Dockerfile)    │
└─────────────────┘ └─────────────────┘ └─────────────────┘
          │                   │                   │
          ▼                   ▼                   ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ API 端点        │ │ 简化 DoC        │ │ 发布说明        │
│ 供当局使用      │ │ (Annex VI)      │ │ 片段            │
└─────────────────┘ └─────────────────┘ └─────────────────┘

生成的制品

从 JSON 生成 CE 标志

CE 标志从 JSON 字段生成，并自动放置在配置的位置（→ 7.7 CE 标志）：

生成的 CE 标志：

  CE [1234]                              ← notified_body（如适用）
  BAUER GROUP                            ← manufacturer.name
  Musterstraße 1, 12345 Musterstadt     ← manufacturer.address
  MinIO Gateway v2.1.0                   ← product.name + product.version

对于容器镜像，还会生成 OCI 标签：

LABEL org.opencontainers.image.ce-marking="conformant"
LABEL eu.cra.doc.url="https://go.bauer-group.com/cra-minio-gateway"
LABEL eu.cra.doc.version="1.0"
LABEL eu.cra.support.end="2031-03-01"

9.1.3 必要内容

根据 CRA，以下信息必须公开可访问，并在声明中汇总：

9.1.4 推荐结构

CRA 合规声明应包含以下部分：

1. 产品标识

• 产品名称、版本、类型（软件 / 容器 / 固件）
• CRA 产品类别（标准 / 第一类 / 第二类 / 关键）
• 唯一标识符（如 Package URL、容器镜像引用）

2. 制造商信息

• 公司、地址
• 安全联系方式（如 disclosure@bauer-group.com）
• 授权代表（如适用）

3. 合规状态

• 采用的合规评估程序（→ 第7章）
• 欧盟符合性声明 (Annex V) 的链接
• CE 标志：状态和位置
• 上次评估日期

4. 安全文档

链接至：

• SBOM (CycloneDX JSON)
• 漏洞披露政策 / SECURITY.md
• 用户信息 (Annex II)
• 技术文档（公开可用部分）

5. 支持期限

• 支持期限的开始和结束
• 当前阶段（主动支持 / 安全支持）
• 更新机制参考（→ 6.3 更新机制）

6. 协调标准

• 采用的协调标准和技术规范
• SBOM 格式标准（如 CycloneDX v1.5）

7. 漏洞管理

• 漏洞披露政策参考
• CVE 监控状态
• 补丁 SLA（→ 3.3 补丁管理）

9.1.5 示例

虚拟产品的 CRA 合规声明示例：

CRA 合规声明

MinIO Gateway — 版本 2.1.0

日期： 2026-03-01 | 制造商： BAUER GROUP

---

字段	值
产品类型	容器镜像
CRA 类别	标准
合规模块	模块 A（内部控制）
CE 标志	✅ 在"关于"对话框和文档中
欧盟符合性声明	[DoC 链接]
SBOM	[CycloneDX JSON — GitHub Release]
SECURITY.md	[链接]
用户信息 (Annex II)	[链接]
支持期限	2026-03-01 至 2031-03-01
漏洞披露	disclosure@bauer-group.com

9.1.6 放置位置

→ 发布策略详情：9.2 发布策略

9.1.7 交叉引用

9.2.1 双重发布概念

合规数据只在一个地方维护——各产品的仓库中。从那里自动发布到中央合规网站。

┌────────────────────┐                ┌──────────────────────────┐
│  产品仓库           │     CI/CD      │  生成的制品               │
│                    │                │                          │
│  .compliance/      │   验证         │  ┌── 合规门户             │
│    cra-statement.  │──────────────→│  │   (HTML/PDF)           │
│    json            │   + 生成       │  ├── CE 标志              │
│                    │                │  │   (关于对话框、README)  │
│  (唯一来源)        │                │  ├── 容器标签             │
│                    │                │  │   (OCI 注解)           │
│                    │                │  ├── 简化 DoC             │
│                    │                │  └── API 端点             │
└────────────────────┘                └──────────────────────────┘
        ↑                                       ↑
   开发人员仅维护                       客户、当局、
   JSON 文件                           公众

9.2.2 优势

9.2.3 仓库结构

每个产品仓库包含一个 .compliance/ 目录：

product-repo/
├── .compliance/
│   ├── cra-statement.json          # 机器可读的 CRA 声明
│   └── README.md                   # 合规结构简要说明
├── SECURITY.md                     # 漏洞披露政策
├── docs/
│   └── compliance/
│       ├── eu-declaration.pdf      # 欧盟符合性声明 (Annex V)
│       └── user-info.md            # 用户信息 (Annex II)
└── ...

文件详情

9.2.4 网站 URL 方案

中央合规门户遵循统一的 URL 结构：

https://cra.app.bauer-group.com/
├── /products/                      # 产品目录
│   ├── /products/{name}/           # 产品合规页面
│   │   ├── /cra                    # CRA 合规声明
│   │   ├── /doc                    # 欧盟符合性声明
│   │   └── /sbom                   # SBOM 下载
│   └── ...
└── /api/                           # （可选）当局 API 访问
    └── /api/products/{name}.json   # 机器可读访问

9.2.5 可访问性

9.2.6 CI/CD 集成

发布集成到现有的 CI/CD 管道中：

创建发布标签
    │
    ├── 1. JSON Schema 验证 (.compliance/cra-statement.json)
    │       → 失败 = 阻止发布
    │
    ├── 2. 完整性检查
    │       → 所有必填字段是否已填写？
    │       → 引用的文档（DoC、SBOM）是否存在？
    │
    ├── 3. 发布到合规门户
    │       → 生成 HTML
    │       → 生成 PDF（可选）
    │
    └── 4. 通知
            → Slack/Teams："产品 {product} v{version} 的合规声明已发布"

9.2.7 交叉引用

报告漏洞

BAUER GROUP 高度重视我们产品的安全性。如果您认为发现了安全漏洞，请按以下方式向我们报告。

首选方式：GitHub 安全公告

对于每个受影响的代码仓库，请使用 Security → Advisories → New Draft Advisory 来保密地报告漏洞。

电子邮件

电子邮件： disclosure@bauer-group.com

请包含以下信息：

• 漏洞描述
• 复现步骤
• 受影响的产品和版本
• 影响评估（如可能）
• 您的联系方式

预期流程

我们的承诺

• 我们不会对善意行事的研究人员采取法律行动
• 我们将感谢您的贡献（经您许可）
• 我们将与您协调披露时间表
• 我们将定期提供状态更新

支持的版本

有关支持的版本和支持期，请参阅各产品的文档。

范围

本策略适用于所有 BAUER GROUP 含数字元素的产品，包括：

• 软件产品（Web 应用、API、库）
• 容器镜像
• 固件（ESP32、STM32、Zephyr）
• 已发布的包（NuGet、NPM）

不在范围内

• 社会工程攻击
• 拒绝服务攻击
• 针对基础设施的物理攻击
• 第三方产品中的漏洞（请向相应的供应商报告）

法规框架

本安全策略符合：

• 网络弹性法案 (EU) 2024/2847 – Art. 13 (6) & (8)
• ISO/IEC 29147:2018 – 漏洞披露 (Vulnerability Disclosure)
• ISO/IEC 30111:2019 – 漏洞处理流程 (Vulnerability Handling Processes)

7.10.1 概述

CRA 的 Annex II 定义了制造商必须向产品用户提供的强制性信息。这些信息必须清晰、易懂，并以用户容易获取的方式提供。

7.10.2 强制性内容

第1项 — 制造商信息

要求： 制造商的名称、注册商号或注册商标以及通讯地址。

BAUER GROUP 的实施方式：

• 每个产品仓库中：README.md 含制造商信息
• 产品网站上：法律声明/版本说明
• 软件中：关于对话框或页脚
• 文档中：扉页

模板规范：

制造商：BAUER GROUP
地址：  [公司地址]
电子邮件：[联系邮箱]
网址：  [产品 URL]

第2项 — 联系点 (Contact Point)

要求： 可报告漏洞的单一联系点，以及制造商的漏洞处理政策。

BAUER GROUP 的实施方式：

• 每个仓库中的 SECURITY.md（模板）
• 联系方式：disclosure@bauer-group.com
• 已启用 GitHub Security Advisories
• 引用披露策略

第3项 — 产品标识

要求： 产品的唯一标识：名称、型号、版本、批号/序列号。

BAUER GROUP 的实施方式：

• 所有软件采用语义化版本管理 (Semantic Versioning, SemVer)
• 容器镜像标签包含 SHA 摘要
• 发布说明包含版本、日期和变更日志
• SBOM 包含唯一产品标识 (CPE/PURL)

第4项 — 预期用途

要求： 产品的预期用途，包括安全环境。

BAUER GROUP 的实施方式：

• 产品描述（参考）：目的、目标受众、部署环境
• 运行条件： 操作系统、网络、硬件要求
• 安全环境： 前提条件（防火墙、VPN、网络分段）
• 限制： 明确记录产品不适用于什么

示例：

预期用途：用于管理[功能]的内部企业应用。
设计用于在企业防火墙后以经认证的访问方式运行。

不适用于：未经网络保护的公开运营、
在关键基础设施 (CRITIS) 中使用。

第5项 — 可预见的误用

要求： 可预见的误用场景的描述。

BAUER GROUP 的实施方式：

• 按产品类型识别典型误用场景
• 文档中的警告通知
• 防止误用的技术保障措施

典型误用场景：

第6项 — SBOM 参考

要求： SBOM 可用性的通知（或获取 URL）。

BAUER GROUP 的实施方式：

• SBOM 作为发布资产发布
• 产品文档中的 SBOM URL
• 机器可读格式的 SBOM（CycloneDX JSON）

模板规范：

SBOM：可在 [Release-URL]/sbom.cdx.json 获取
格式：CycloneDX JSON v1.6
已签名：是（Cosign）

详情：SBOM与签名

第7项 — 支持期限

要求： 提供安全更新的期限，至少5年或预期产品生命周期。

BAUER GROUP 的实施方式：

• 支持期限记录在产品文档中
• 每个仓库的 SECURITY.md 中
• 产品网站上
• 发布说明中

详情：支持与生命周期

第8项 — 安装指南和安全配置

要求： 产品安全安装、配置、调试和使用的说明。

BAUER GROUP 的实施方式：

• 安装指南： 包含安全注意事项的分步说明
• 加固指南： 推荐的安全配置
• 检查清单： 安装后安全检查清单
• 最低要求： 已记录的系统先决条件

安装指南的内容：

1. 系统先决条件（包括安全要求）
2. 包含完整性验证的安装步骤
3. 初始设置（密码、MFA、网络）
4. 推荐的安全配置（加固）
5. 更新配置（自动/手动）
6. 备份设置

第9项 — EU 符合性声明

要求： EU 符合性声明 (EU Declaration of Conformity) 的引用或带 URL 的简化版本。

BAUER GROUP 的实施方式：

• 产品文档中的 EU 符合性声明 URL
• 根据 Annex VI 的简化版本（-> 简化 DoC）

第10项 — 更新信息

要求： 关于安全更新类型和位置的信息。

BAUER GROUP 的实施方式：

• 发布渠道已记录（GitHub Releases、Container Registry、OTA）
• 通知渠道（GitHub Watch、电子邮件、RSS）
• 文档中的更新说明

7.10.3 模板：用户信息

可填写模板：用户信息/产品安全信息

7.10.4 检查清单：Annex II

• [ ] 产品和文档中有制造商信息
• [ ] SECURITY.md 包含联系点和 CVD 策略
• [ ] 唯一产品标识（SemVer、摘要）
• [ ] 预期用途已记录
• [ ] 可预见的误用场景已识别并处理
• [ ] 产品文档中有 SBOM 参考
• [ ] 支持期限已确定并传达
• [ ] 包含安全注意事项的安装指南
• [ ] EU 符合性声明的引用
• [ ] 更新信息（渠道、通知、说明）

7.9.1 概述

除了完整的 EU 符合性声明（Annex V）外，CRA 还允许根据 Annex VI 使用简化版本 (Simplified EU Declaration of Conformity)。前提是完整版本可在线获取时，简化版本可随产品提供。

7.9.2 何时使用简化版本？

7.9.3 强制性内容（Annex VI）

简化 EU 符合性声明至少应包含：

1. 制造商信息

[制造商名称]
声明以下含数字元素的产品

2. 产品标识

[产品名称、型号、版本]

3. 合规声明

符合 Regulation (EU) 2024/2847
（Cyber Resilience Act）的规定。

4. 完整声明的 URL

完整的 EU 符合性声明请见：
[URL]

7.9.4 模板：简化 EU 符合性声明

## EU 符合性声明（简化版）

**BAUER GROUP** 特此声明，产品

**[产品名称] v[版本]**

符合 Regulation (EU) 2024/2847
（Cyber Resilience Act）的规定。

完整的 EU 符合性声明请见：
> [完整 DoC 的 URL]

支持期限：[日期] 至 [日期]
联系方式：[电子邮件]

7.9.5 放置位置

软件产品

• 仓库中的 README.md
• 应用程序中的关于对话框或页脚
• 每个版本的发布说明
• 产品网站
• 容器镜像标签（OCI Annotations）

固件/硬件

• 包装（印刷或附页）
• 快速入门指南
• 产品标签（带 URL 的二维码）

7.9.6 容器镜像标签示例

LABEL eu.cra.doc.url="https://go.bauer-group.com/cra-[product]"
LABEL eu.cra.doc.version="1.0"
LABEL eu.cra.support.end="2031-12-31"

7.9.7 与 Annex V 的关系

完整版：EU 符合性声明（Annex V）

可填写模板：EU 符合性声明模板

4.4.1 概述

沟通计划定义了安全事件的内部和外部沟通渠道。目标是快速、一致且符合法律要求的信息共享。

4.4.2 沟通矩阵

内部沟通

外部沟通

4.4.3 沟通模板

内部初始通知（Teams）

🚨 安全事件 – SEV-[1/2/3/4]

产品：[产品名称] v[版本]
漏洞：[CVE-ID 或简要描述]
严重程度：[CRITICAL/HIGH/MEDIUM/LOW]
是否被积极利用：[是/否/未知]
是否须向 ENISA 报告：[是/否]

状态：[分类/遏制/修复/已关闭]
后续步骤：[描述]
负责人：[姓名]

事件工单：[GitHub Issue 链接]

外部用户通知

安全通知 – [产品名称]

尊敬的用户，

我们已在 [产品名称] 中识别并修复了一个安全漏洞。

受影响版本：[版本]
修复版本：[版本]
严重程度：[CRITICAL/HIGH]
CVE：[CVE-ID]

建议操作：
请更新至版本 [X.Y.Z]。

详情：[安全公告链接]

如有疑问，请联系：disclosure@bauer-group.com

4.4.4 升级路径

SEV-1（严重）：
开发人员 → 安全负责人 → 管理层 → ENISA（24 小时）
                                 → 用户（立即）

SEV-2（高）：
开发人员 → 安全负责人 → 管理层（通知）
                      → 用户（修复后）

SEV-3（中）：
开发人员 → 安全负责人 → 在下一版本中修补

SEV-4（低）：
开发人员 → 待办事项 → 常规发布

4.4.5 Teams 集成

现有的 Teams 通知（teams-notifications.yml）将针对安全事件进行扩展：

• 事件频道： 专用于安全事件的 Teams 频道
• 自动告警： 针对来自 CVE 监控的 CRITICAL/HIGH CVE 发现
• 状态更新： 事件工单状态变更时自动更新

4.4.6 文档记录要求

安全事件相关的所有沟通均须记录：

• 每次沟通的时间戳
• 接收方和渠道
• 内容（摘要）
• 接收确认

该文档是事件工单的一部分，作为面向监管机构的证据。

4.2.1 协调漏洞披露 (Coordinated Vulnerability Disclosure, CVD)

本政策定义了根据 CRA Art. 13(6) 和 ISO/IEC 29147:2018 进行协调漏洞披露 (Coordinated Vulnerability Disclosure) 的流程。

4.2.2 适用范围

本政策适用于 BAUER GROUP 的所有含数字元素的产品 (Products with Digital Elements)，包括：

• 软件产品（Web 应用程序、API、库）
• 容器镜像
• 固件 (Firmware)（ESP32、STM32、Zephyr）
• 可公开访问的服务

4.2.3 报告渠道

1. GitHub Security Advisories（首选）

每个代码仓库： Security → Advisories → New Draft Advisory

优势：

• 机密通信
• 集成 CVE 分配
• 在私有分支中进行补丁协调
• 结构化记录

2. 电子邮件

地址： disclosure@bauer-group.com

• 加密：PGP 密钥在代码仓库中（SECURITY.md）
• 语言：德语或英语

3. SECURITY.md

每个代码仓库包含一个 SECURITY.md，其中包含：

• 报告渠道
• PGP 密钥（或链接）
• 支持的版本
• 响应时间

4.2.4 外部报告者流程

我们的期望

报告漏洞的安全研究人员应：

• 在修复方案可用之前不公开披露漏洞
• 不窃取或销毁任何数据
• 不进行拒绝服务攻击
• 给予合理的修复时间

我们的承诺

披露时间线

第 0 天：  漏洞报告
第 2 天：  确认收到
第 7 天：  初步评估和严重程度分类
第 14 天： 向报告者提供状态更新
第 28 天： 向报告者提供状态更新
第 60 天： 补丁应已开发完成
第 90 天： 协调漏洞披露（默认截止日期）
           ├── 发布安全公告
           ├── 分配 CVE-ID
           ├── 发布补丁版本
           └── 在公告中致谢报告者（应要求）

4.2.5 接收报告的内部流程

外部漏洞报告
    │
    ├── 1. 确认收到（≤ 48 小时）
    │   └── 自动或由安全负责人确认
    │
    ├── 2. 分类（≤ 7 天）
    │   ├── 复现漏洞
    │   ├── 评估严重程度 (CVSS)
    │   ├── 识别受影响产品
    │   └── 检查：是否正在被积极利用？
    │       └── 是 → ENISA 报告义务 + 加速修复
    │
    ├── 3. 补丁开发
    │   ├── 开发修复方案（如适用在私有分支中）
    │   ├── 进行测试
    │   └── 安全审查
    │
    ├── 4. 协调漏洞披露
    │   ├── 与报告者协商时间
    │   ├── 准备安全公告
    │   ├── 申请 CVE-ID（通过 GitHub 或 MITRE）
    │   └── 准备补丁版本
    │
    └── 5. 发布
        ├── 发布安全公告
        ├── 发布补丁版本
        ├── 更新 SBOM
        ├── 通知用户
        └── 感谢并致谢报告者

4.2.6 安全港 (Safe Harbor)

BAUER GROUP 不会对以下安全研究人员采取法律行动：

• 善意行事
• 遵守本披露政策
• 未经授权不访问、复制或销毁数据
• 不通过拒绝服务损害服务
• 不危及受影响的第三方

4.2.7 合规参考

9.3.1 目的

机器可读的合规数据可实现：

• 自动发布 到合规门户（→ 9.2）
• CI/CD 管道中的程序化验证
• 跨所有产品的中央仪表板聚合
• 当局通过 API 访问 供市场监督当局使用

9.3.2 JSON Schema

CRA 合规声明遵循已定义的 JSON Schema：

{
  "$schema": "https://cra.app.bauer-group.com/schemas/cra-statement/v1.json",
  "schema_version": "1.0.0",

  "manufacturer": {
    "name": "BAUER GROUP",
    "address": "[完整邮寄地址]",
    "contact_email": "disclosure@bauer-group.com",
    "website": "[URL]"
  },

  "product": {
    "name": "[产品名称]",
    "version": "[X.Y.Z]",
    "type": "[software|container|firmware|embedded]",
    "description": "[简要描述]",
    "identifier": "[Package URL 或容器镜像引用]"
  },

  "cra_classification": {
    "category": "[standard|class_i|class_ii|critical]",
    "conformity_module": "[module_a|module_bc|module_h|eucc]",
    "notified_body": "[名称和识别号，或 null]"
  },

  "conformity": {
    "declaration_url": "[完整 DoC (Annex V) 的 URL]",
    "declaration_date": "[YYYY-MM-DD]",
    "ce_marking": true,
    "ce_marking_placement": "[about_dialog|documentation|website|container_label]",
    "last_assessment_date": "[YYYY-MM-DD]"
  },

  "security_documentation": {
    "sbom_url": "[SBOM (CycloneDX JSON) 的 URL]",
    "sbom_format": "CycloneDX",
    "sbom_version": "1.5",
    "security_policy_url": "[SECURITY.md 的 URL]",
    "user_info_url": "[用户信息 (Annex II) 的 URL]",
    "disclosure_contact": "disclosure@bauer-group.com"
  },

  "support_period": {
    "start_date": "[YYYY-MM-DD]",
    "end_date": "[YYYY-MM-DD]",
    "phase": "[active|security|eol]",
    "update_mechanism": "[auto|manual|notification]"
  },

  "harmonised_standards": [
    {
      "identifier": "[如 EN XXXXX:YYYY]",
      "description": "[描述]"
    }
  ],

  "metadata": {
    "generated_at": "[ISO 8601 时间戳]",
    "generator": "[工具或手动]",
    "statement_version": "[声明版本]"
  }
}

9.3.3 字段概览

必填字段

可选字段

9.3.4 验证

CI/CD 管道

应将 cra-statement.json 的验证集成到 CI/CD 管道中：

# 示例：GitHub Actions 步骤
- name: Validate CRA Statement
  run: |
    npx ajv validate \
      -s schemas/cra-statement-v1.schema.json \
      -d .compliance/cra-statement.json

验证规则

9.3.5 完整示例

{
  "$schema": "https://cra.app.bauer-group.com/schemas/cra-statement/v1.json",
  "schema_version": "1.0.0",

  "manufacturer": {
    "name": "BAUER GROUP",
    "address": "Musterstraße 1, 12345 Musterstadt, Deutschland",
    "contact_email": "disclosure@bauer-group.com",
    "website": "https://www.bauer-group.com"
  },

  "product": {
    "name": "MinIO Gateway",
    "version": "2.1.0",
    "type": "container",
    "description": "S3 兼容对象存储网关",
    "identifier": "ghcr.io/bauer-group/minio-gateway:2.1.0"
  },

  "cra_classification": {
    "category": "standard",
    "conformity_module": "module_a",
    "notified_body": null
  },

  "conformity": {
    "declaration_url": "https://cra.app.bauer-group.com/products/minio-gateway/doc",
    "declaration_date": "2026-03-01",
    "ce_marking": true,
    "ce_marking_placement": "about_dialog",
    "last_assessment_date": "2026-03-01"
  },

  "security_documentation": {
    "sbom_url": "https://github.com/bauer-group/minio-gateway/releases/download/v2.1.0/sbom.cdx.json",
    "sbom_format": "CycloneDX",
    "sbom_version": "1.5",
    "security_policy_url": "https://github.com/bauer-group/minio-gateway/blob/main/SECURITY.md",
    "user_info_url": "https://cra.app.bauer-group.com/products/minio-gateway/user-info",
    "disclosure_contact": "disclosure@bauer-group.com"
  },

  "support_period": {
    "start_date": "2026-03-01",
    "end_date": "2031-03-01",
    "phase": "active",
    "update_mechanism": "auto"
  },

  "harmonised_standards": [
    {
      "identifier": "CycloneDX v1.5",
      "description": "SBOM 格式 (OWASP)"
    },
    {
      "identifier": "ISO/IEC 29147:2018",
      "description": "漏洞披露"
    }
  ],

  "metadata": {
    "generated_at": "2026-03-01T10:00:00Z",
    "generator": "manual",
    "statement_version": "1.0.0"
  }
}

9.3.6 Schema 版本控制

9.3.7 交叉引用

6.1.1 模板：根据 CRA Annex VII 编制的产品描述

1. 产品标识

2. 预期用途 (Intended Use)

描述： [描述产品的预期用途、目标受众和预期运行环境。]

使用环境：

• [例如：云基础设施、本地部署、嵌入式设备、IoT]
• [操作系统/平台]
• [是否需要网络连接：是/否]

3. CRA 产品分类

4. 技术描述

架构概述： [从高层次描述软件架构]

技术栈：

接口：

5. 安全功能

6. 依赖项

SBOM 参考： [链接至当前 SBOM]

关键第三方组件：

7. 支持期限 (Support Period)

8. 合规性

A.9.1 模板：公开 CRA 合规声明

此模板作为产品特定公开 CRA 合规声明的基础。它将所有 CRA 相关信息汇总在一个页面上，并链接到相关详细文档。

A.9.2 CRA 合规声明

[产品名称] — 版本 [X.Y.Z]

日期： [YYYY-MM-DD] | 制造商： BAUER GROUP

1. 产品标识

2. 制造商

3. 合规状态

4. 安全文档

5. 支持期限

6. 协调标准和技术规范

7. 漏洞管理

A.9.3 机器可读格式

与人类可读版本并行，此声明作为 cra-statement.json 在产品仓库中维护：

→ 9.3 机器可读格式

→ 9.2 发布策略

A.9.4 更新

此声明在以下情况下更新：

• 新的主要/次要版本发布
• CRA 产品类别变更
• 协调标准变更
• 支持期限变更

详细维护流程：→ 9.4 维护与更新

A.3.1 模板：根据 Art. 14(2)(a) CRA 的预警

1. 制造商标识

2. 通知类型

• [ ] 主动利用漏洞 (Art. 14(1))
• [ ] 严重安全事件 (Art. 14(3))

3. 受影响产品

4. 漏洞/事件

5. 初步影响评估

6. 即时措施

7. 后续步骤

• [ ] 详细分析（72小时内）
• [ ] 补丁开发（预计完成时间：[日期]）
• [ ] 用户通知（预计完成时间：[日期]）
• [ ] 向 ENISA 发送后续通知（<=72小时）

注意： 此预警将在 72 小时内由详细的漏洞通知予以补充。

A.5.1 模板：根据 Art. 14(2)(c) CRA 的最终报告

1. 先前通知参考

2. 制造商标识

3. 摘要

[用 3-5 句话简要概述事件]

4. 完整时间线