围绕欧盟 CRA 漏洞上报开展项目准备时，法规范围、产品实现与测试证据需要相互对应。本期查阅ETSI 官方资讯的公开资料，从三个工程环节梳理可执行的验证方法。下述内容属于检测准备建议，不把通用实践表述为该制度的逐条强制要求；产品适用范围、正式条款及申报程序应以来源页面和现行原文为准。
1、法规适用性与技术测试为什么要分开确认
同一款联网设备进入不同市场，可能面对不同的适用范围、排除情形和经营主体责任。建议先按实际销售用途、连接能力、数据处理和配套服务描述产品，再对照官方法规及实施指引判断适用性。技术功能相近，不代表不同制度的符合性声明、标签申请或证据留存要求可以直接互换；测试结论也不应扩大为对所有市场的准入承诺。
实际准备时，可建立“产品特征—适用依据—待核实问题”的清单，将法律范围判断与工程测试任务分别分配负责人。涉及草案或标准修订时，应记录资料版本、查询日期及当前状态，避免把征求意见稿当作已经生效的统一要求。对暂不能确定的边界，宜取得主管机构或专业人员的明确意见，再锁定测试计划。这样的流程有助于减少因范围判断错误导致的重复送检和材料返工。
2、组件清单怎样支撑漏洞影响判断
组件清单的价值，在于把软件成分与实际发布产品对应起来。建议同时关注设备固件、移动应用、服务端和供应商二进制，记录组件名称、精确版本、来源、依赖关系以及所属构建。仅整理直接依赖，或只填写大版本号，往往不足以定位一个公开漏洞究竟影响哪些产品，也不便于区分源码、构建结果与最终烧录镜像之间的差异。
可从一份实际发布包抽样核对清单：比较库文件和包管理记录，检查构建时禁用的功能是否仍被带入镜像，再将已知问题映射到可达代码和暴露接口。命中漏洞编号不应自动等同于能够被利用，但“扫描未发现”也不能替代清单完整性检查。建议为每个发布版本保留不可混淆的清单快照，记录影响分析、处置决定和复测结果，使后续补丁处理有据可查。
3、测试证据如何对应型号与软件版本
一份测试结果能否复用，取决于证据是否能准确关联到实际产品。建议在测试前固定样机型号、硬件修订、固件构建号、应用版本和关键服务端配置，记录测试账号权限、开关选项及外部依赖。对平台化产品，还应维护差异表，明确哪些型号共用机制，哪些接口、存储能力或业务功能需要补充验证。
可以抽取一条整改记录做反向追溯：从结论找到对应请求、截图和日志，再定位到运行版本、变更提交和复测条件。如果中间存在无法确认的环节，就需要补齐证据，而不能只以研发人员的口头说明代替。建议把未测范围、假设条件和不适用理由一并保留，并为关键附件记录摘要或归档编号。项目交接时，另一位工程师应能根据这些资料复现主要结果，辨别结论是否仍适用于当前发布版本。
送检前的资料核对
建议将上述检查结果纳入同一份项目问题清单，明确责任人、待补充证据和复测条件。对无法复现或仍依赖外部条件的结论，应保留其限制，不用一次工具扫描结果替代完整判断。技术、质量与产品负责人可据此确认下一步安排，减少样机、资料与实际交付版本不一致造成的返工。
联系我们
深圳市领世达检测技术有限公司提供产品网络安全检测与合规技术支持。客服热线：400-661-8031；联系电话：185-9801-0056。地址：广东省深圳市宝安区福永街道智美汇志科技园。