5.3 第三方评估
5.3.1 第三方组件评估
根据 Art. 13(5) CRA，制造商在集成第三方组件时必须履行尽职调查 (Due Diligence) 义务。本页描述了评估流程。
两项独立义务，一个目标
CRA 设立了两项相互独立但彼此互补的义务。混淆二者是常见的缺口来源。
| 网络安全风险评估 (Art. 13(2)) | 尽职调查 (Art. 13(5)) | |
|---|---|---|
| 对象 | 含数字元素的产品本身，包括源自产品之外的风险——外部网络、环境因素、外部基础设施 | 构成产品一部分的要素，尤其是第三方提供的集成软件或硬件组件 |
| 问题 | 什么可能影响我们的产品，我们如何在产品中加以缓解？ | 这些组件是否满足我们的产品对其的要求，从而不会损害产品的合规性？ |
| 产出 | 落实附件 I 第一部分的产品层面安全措施 | 已核实的证据，证明每个组件满足所识别的要求 |
尽职调查的实际做法
履行尽职调查的方式是：确定产品为达成其网络安全目标而对组件的要求，随后以风险导向的方式核实这些组件符合产品的需要（鉴于条款 34）。
制造商应与风险评估保持一致，识别集成组件必须满足的要求。若产品依赖某组件提供的加密功能、更新机制或安全通信，制造商必须识别这些需要并核实该组件确能满足。
可接受的证据
| 证据 | 说明 |
|---|---|
| 组件制造商的技术规格 | 基础 |
| 组件制造商的安全文档 | 基础 |
| 相关的合规或保证文件 | 例如组件制造商自身的 CRA 合规证据 |
| 自行测试 | 在适当情形下，用以核实组件确能充分执行相关功能 |
尽职调查支撑自身的合规
尽职调查是一项独立的法定义务，同时也支撑制造商证明产品整体符合基本要求的能力。
制造商自行开发某项功能时，必须直接落实基本要求。集成他人开发的组件时，必须通过尽职调查确保该组件的使用方式能使产品整体合规。两种情形下的目标完全相同。
集成 ≠ 自行开发
物理或逻辑上被集成进产品、但来源于第三方的组件，必须纳入风险评估。但就合规目的而言，它们被视为由外部供应、其属性在集成时通过尽职调查加以核实的组件——制造商可能既未重新设计也未重新开发它们。
5.3.2 评估框架
自动化检查（针对每个依赖项）
这些检查在 CI/CD 流水线中自动执行：
| 检查项 | 工具 | 是否阻止构建 |
|---|---|---|
| 已知 CVE (CRITICAL) | Trivy / Grype | ✅ |
| 已知 CVE (HIGH) | Trivy / Grype | ✅ |
| 禁止的许可证 | License Compliance | ✅ |
| 暴露的密钥 | Gitleaks / GitGuardian | ✅ |
人工审查（针对新的关键依赖项）
在安全关键领域引入新依赖项时，需进行额外的人工评估：
| 标准 | 评估内容 | 权重 |
|---|---|---|
| 维护者声誉 | 已验证的账户、知名组织 | 高 |
| 项目活跃度 | 定期提交、积极解决 Issue | 高 |
| 安全响应 | 对已报告漏洞的响应时间 | 高 |
| 代码质量 | 测试、CI/CD、代码审查 | 中 |
| 依赖深度 | 传递依赖（越少越好） | 中 |
| 替代方案 | 是否有更安全的替代方案？ | 中 |
| 采用率 | 下载量、用户群 | 低 |
评级量表
| 评级 | 含义 | 操作 |
|---|---|---|
| A -- 可信 | 所有标准均满足，积极维护 | 批准使用 |
| B -- 可接受 | 存在轻微限制，整体可信 | 在监控下使用 |
| C -- 存在风险 | 存在显著限制 | 仅在有合理理由 + 审查后使用 |
| D -- 不可接受 | 存在关键限制 | 禁止使用 |
5.3.3 特殊情况：厂商 SDK（嵌入式）
对于固件项目，厂商 SDK（ESP-IDF、STM32 HAL、Zephyr）需单独评估：
| SDK | 评级 | 理由 |
|---|---|---|
| ESP-IDF (Espressif) | A | 官方 SDK，积极维护，SBOM 可用 |
| STM32 HAL (STMicroelectronics) | A | 官方 SDK，工业级 |
| Zephyr RTOS | A | Linux Foundation 项目，Security WG 活跃 |
| PlatformIO | B | 社区项目，广泛采用 |
5.3.4 持续监控
所有集成的第三方组件在集成后持续监控：
- Dependabot -- 每周检查新版本和 CVE
- CVE 监控 -- 每日将 SBOM 与当前 CVE 数据库进行比对扫描
- 许可证合规 -- 每次构建时检查
- 基础镜像监控 -- 每周检查新的基础镜像版本
5.3.5 第三方远程服务与云服务商
若产品依赖某项并非远程数据处理解决方案的远程方案——因其并非由 BAUER GROUP 或为 BAUER GROUP 设计和开发——则该方案按集成组件处理：评估其集成风险、在产品层面加以缓解，并履行与之等同的尽职调查义务，其力度与该远程方案带来的风险相称。判定方法见 1.15 远程数据处理。
可复用的保证材料
以下证据可用于支撑合规评估以及对第三方远程服务的尽职调查：
| 材料 | 依据 |
|---|---|
| 履行委员会实施法规 (EU) 2024/2690 项下义务的证据 | NIS2 实施法案 |
| 履行 (EU) 2022/2554 法规项下义务的证据 | DORA |
| 依欧洲网络安全认证方案取得的符合性声明或证书 | (EU) 2019/881 法规（网络安全法） |
| 符合 ISO/IEC 27017:2015 或 ISO/IEC 27001:2022 的证据 | 国际标准 |
合同措施
制造商必须基于其风险评估落实最适当的安全措施，并在相关情形下借助供应商的责任共担模型。缓解措施既包括产品层面的安全控制，也包括对供应商自身安全措施的核实。
在 SLA 中嵌入安全保证
缓解此类风险的一项实用工具，是在与第三方供应商的服务级别协议中嵌入安全保证——包括供应商妥善处理漏洞的承诺。
当供应商作出变更时
供应商变更不是实质性修改 —— 但它是触发点
第三方远程服务供应商所提供方案的重大变更，不构成产品的实质性修改，因为这些要素不在制造商责任范围内。
但它要求制造商采取行动：
- 作为尽职调查的一部分，确保供应商就其所作变更充分告知 BAUER GROUP。
- 据此修订风险评估。
- 追问供应商是否仍提供充分的网络安全保证，以及产品层面的控制措施是否仍然充分。
- 若否，则调整控制措施或更换供应商。
5.3.6 文档
对于技术文档 (Technical Documentation)（Annex VII CRA），需维护所有第三方组件的列表：
- SBOM 作为机器可读的清单
- 组件要求登记册逐组件记录产品对其的要求（加密、更新机制、安全通信……）以及据以核实的证据——这是 Art. 13(5) 义务的可审计形式
- 人工评估存储在产品文档文件夹中
- 从第三方远程服务供应商取得的保证材料随产品档案归档
- 许可证合规报告作为构建工件存档
5.3.1 与 5.3.5 节解释的来源与法律地位：欧盟委员会 CRA 指南。