一份渗透测试报告，不等于 CRA 技术文档
把产品身份、网络安全风险、漏洞处理、支持期与合格评定记录连成一张 CRA 技术文档证据图，再确定咨询项目范围。
重点监测信号
- 群里说清了产品发布日期，安全材料却对应另一个版本或上游组件
- 有人把渗透测试当作整套 CRA 技术文档，但安全开发与漏洞处理没有记录
- 声明或 CE 标志期限已经出现，证据负责人和合格评定路径仍不清楚
《Cyber Resilience Act》（CRA，《网络韧性法案》）技术文档不是一个装满安全文件的目录。它要支持一家制造商对一个具体产品版本作出的主张：产品是什么、评估了哪些网络安全风险、怎样满足适用要求、支持期内如何处理漏洞，以及用哪条合格评定路径进入欧盟市场。
**定义：**CRA 技术文档是 Regulation (EU) 2024/2847 要求的产品级合规记录。Annex VII 把产品描述、设计开发材料、网络安全风险评估、漏洞处理流程、测试报告和合格评定证据连在一起。咨询接件时应检查这些连接，而不是只数文件数量。
五条连接断了一条，文件夹再满也不完整
网络安全合规咨询业务负责人可能查看企业主动连接且有权访问的嵌入式设备、软件制造商、安全实验室与欧盟产品合规 Telegram 群。群里可能出现这样的模拟片段：
“CRA 文件快齐了，5 月渗透测试通过，SBOM 在研发那边。”
“经销商审查前要声明，但不确定报告测的是不是 v2 板卡。”
这不是真实客户消息，也不是合规结论。制造商、产品类别、准确版本、测试范围、未解决问题、支持期和评定路径都不知道。晚一天看到，最具体的损失可能是经销商审查或设计冻结继续使用了错误版本的证据。应先保住五条连接：
- **产品到预期用途：**商品名、型号、软硬件版本、交付功能和运行环境。
- **产品到风险评估：**资产、威胁、暴露面、可合理预见的使用、适用要求和处置决定。
- **风险到实现证据：**架构、安全开发控制、测试、更新机制和组件决定。
- **产品到漏洞处理：**接收、协调披露、分级、修复、安全更新交付与支持期内的留档。
- **证据到合规主张：**产品类别、采用的标准或规范、评定路径、声明材料和负责制造商。
材料无法连接时，明确写成“缺失”“属于其他版本”“尚未审查”或“负责人未知”。“在安全盘里”不是可审查状态。
测试只能回答它实际测试过的问题
渗透测试能说明某个构建版本在特定日期、范围和环境下的表现。它不能单独证明制造商评估了全部相关风险、建立了可重复的安全开发流程、能向用户交付安全更新、会接收漏洞报告，也不能决定合格评定路径。
SBOM（software bill of materials，软件物料清单）同样有边界。它可以列出软件组件，帮助匹配依赖和受影响版本；但它不能证明组件风险已经判断、修复能送达用户或 Annex I 的每项要求已经满足。NIST SSDF 供应商证据图可以用来交叉检查安全开发，但 NIST SP 800-218 不能代替 CRA 法规。
每份报告至少记录受测版本、环境、日期、范围、排除项、发现、处置与批准人，再把结果指向它所支持的风险或要求。没有主张的证据难以评估；没有证据的主张难以复核。
漏洞处理必须落到具体产品记录
CRA 法规Annex I 同时覆盖产品网络安全属性和漏洞处理要求。因此，一份公司级制度不够。产品记录应能说明：如何收到报告，怎样把受影响组件匹配到已交付版本，谁判断严重性与可利用性，谁批准修复，用户如何收到安全更新，以及每个动作怎样留存。
例如，“已审查 OpenSSL 漏洞”信息太少。证据行应写明组件版本、包含它的产品、可达性或暴露分析、决定、适用时的修复版本、发布渠道和通知负责人。如果上游公告不影响已交付配置，也要保留判断理由。
CRA 支持期证据文章说明预期使用时间和公开结束日期怎样影响漏洞处理；CRA 报告工作流文章处理已被主动利用的漏洞和严重事件。这两者都不能代替产品级技术文档。
先把法律日期和产品事件放在一起
Article 71 规定 CRA 自 2027 年 12 月 11 日起普遍适用；Article 14 报告义务自 2026 年 9 月 11 日起适用。2026 年 8 月出现的需求可能是在准备普遍适用阶段，也可能是在搭建提前生效的报告工作流，不能因为 Article 14 临近就声称全部 Article 13 义务已经普遍适用。
法律日期旁边还要写产品事件：设计冻结、供应商更换、预约实验室、批准声明、首次进入欧盟市场，还是更新已上市产品。事件决定哪份证据已经迟到，以及谁有权限提供记录。
可报价的第一份交付物，是断点清单
第一阶段可以交付证据索引：每项适用要求对应产品版本、主张、证据对象、来源位置、负责人、审查状态和未决问题。第二阶段再处理缺口，例如风险决定缺失、版本不一致、漏洞记录为空、支持日期无依据或评定路径未定。
TOP Prospect 可以整理用户主动连接且有权访问的 Telegram 来源片段，保留原文、来源、时间与排序理由供人工复核。当前匹配目标界面只保存配置，不会自动生成新候选。它不能检查技术文件、认证事实、决定 CRA 范围或签署声明。Telegram 商业信号工作流说明了这些边界。
关键事实
- CRA 是 Regulation (EU) 2024/2847，适用于在欧盟市场提供的含数字元素产品。
- 技术文档必须支持明确的产品版本和适用网络安全要求。
- 漏洞处理证据要覆盖产品级接收、评估、修复、更新与留档。
- 渗透测试或 SBOM 可以支持技术文档，但不能证明全部合规主张。
- CRA 自 2027 年 12 月 11 日起普遍适用；Article 14 报告义务自 2026 年 9 月 11 日起适用。
- 产品类别、评定路径、实际文件内容与合规状态，都要等授权记录审查后才能确认。
常见问题
一份渗透测试报告足以构成 CRA 技术文档吗？
不足。它可以支持部分网络安全评估，但技术文档还要说明产品、设计开发证据、网络安全风险评估、漏洞处理流程，以及适用于该版本的合格评定证据。
SBOM 能证明产品符合 CRA 吗？
不能。SBOM 可以支持组件与漏洞管理，却不能单独证明安全开发、更新交付、风险处置、合格评定或全部 Annex I 要求。
CRA 何时普遍适用？
Regulation (EU) 2024/2847 自 2027 年 12 月 11 日起普遍适用；Article 14 报告义务提前自 2026 年 9 月 11 日适用。
咨询公司报价前应索取哪些材料？
索取准确产品及版本、预期用途、制造商角色、架构和组件记录、网络安全风险评估、安全开发与漏洞处理记录、支持期决定、测试证据和拟采用的合格评定路径。
TOP Prospect 编辑团队于 2026 年 8 月 20 日依据 Regulation (EU) 2024/2847、European Commission 现行 CRA 材料与 NIST SP 800-218 复核。本文不是法律意见或合格评定。
常见问题
一份渗透测试报告足以构成 CRA 技术文档吗？
不足。它可以支持部分网络安全评估，但技术文档还要说明产品、设计开发证据、网络安全风险评估、漏洞处理流程，以及适用于该版本的合格评定证据。
SBOM 能证明产品符合 CRA 吗？
不能。软件物料清单可以支持组件与漏洞管理，却不能单独证明安全开发、更新交付、风险处置、合格评定或全部 Annex I 要求。
CRA 何时普遍适用？
Regulation (EU) 2024/2847 自 2027 年 12 月 11 日起普遍适用；Article 14 的报告义务提前自 2026 年 9 月 11 日适用，两个日期不能混用。
咨询公司报价前应索取哪些材料？
索取准确产品及版本、预期用途、制造商角色、架构和组件记录、网络安全风险评估、安全开发与漏洞处理记录、支持期决定、测试证据和拟采用的合格评定路径。
资料来源与延伸阅读
值得关注的潜在线索 Signal 是怎样被发现的
了解 Top商业线索怎样发现和整理值得核实的 Signal、保留 Telegram 原始上下文、去掉重复消息并安排查看顺序。是否跟进以及下一步做什么，仍由用户决定。
