From 76627e35522a95dcb23c93b0288270f9e39dc00a Mon Sep 17 00:00:00 2001
From: test <test>
Date: Mon, 10 Aug 2026 09:19:49 +0000
Subject: [PATCH] =?UTF-8?q?=E2=80=9C=E6=BC=8F=E6=B4=9E=E6=B8=85=E9=9B=B6?=
 =?UTF-8?q?=E2=80=9D=20=E4=BB=8E=E6=95=B0=E9=87=8F=E5=90=88=E8=A7=84?=
 =?UTF-8?q?=E5=88=B0=E7=BB=93=E6=9E=9C=E5=90=88=E8=A7=84=E3=80=81?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 data.json                                     |   3 +-
 ...��零” 从数量合规到结果合规.md | 244 ++++++++++++++++++
 2 files changed, 246 insertions(+), 1 deletion(-)
 create mode 100644 doc/2026-08/“漏洞清零” 从数量合规到结果合规.md
diff --git a/data.json b/data.json
index c2e83d43..a1b85149 100644
--- a/data.json
+++ b/data.json
@@ -21985,5 +21985,6 @@
     "https://mp.weixin.qq.com/s/cZQMfzJhKPT6AwgjoT2wWw": "CNNVD通报OpenClaw多个安全漏洞",
     "https://mp.weixin.qq.com/s/0BkiOD8GrBTgLsF7InfNIw": "【安全圈】电商平台前员工利用系统漏洞，0元购3000多件家电",
     "https://mp.weixin.qq.com/s/Fqby_u4cAGcGi_cR578zmA": "漏洞预警： 普华PowerPMS两漏洞组合 无需账号拿下服务器",
-    "https://mp.weixin.qq.com/s/eH9vKnecA8Ajq-4w2nhdsQ": "自动挖上传漏洞，这款工具真的强"
+    "https://mp.weixin.qq.com/s/eH9vKnecA8Ajq-4w2nhdsQ": "自动挖上传漏洞，这款工具真的强",
+    "https://mp.weixin.qq.com/s/MlbLQTc0AWo4eIqlANimQw": "“漏洞清零” 从数量合规到结果合规"
 }
\ No newline at end of file
diff --git a/doc/2026-08/“漏洞清零” 从数量合规到结果合规.md b/doc/2026-08/“漏洞清零” 从数量合规到结果合规.md
new file mode 100644
index 00000000..9cd93830
--- /dev/null
+++ b/doc/2026-08/“漏洞清零” 从数量合规到结果合规.md	
@@ -0,0 +1,244 @@
+#  “漏洞清零” 从数量合规到结果合规  
+摄星
+                    摄星  数世咨询   2026-08-10 08:00  
+  
+将"高危漏洞清零"或"漏洞扫描结果清零"写入运营目标与团队考核，是漏洞运营管理的通行做法。其考核对象是未修复漏洞的条数与超期天数，主要证据是扫描报告与工单关闭记录，达标标志是数字归零。  
+  
+这一做法隐含一个前提：修复能力足以覆盖发现总量，修复速度足以覆盖漏洞增长速度。该前提在实践中并不成立。  
+  
+当目标确定无法达成而考核压力持续存在时，运营者的理性反应不是修复更多漏洞，而是让漏洞在报表上消失：隐藏资产与漏洞数据、把未修复项标记为误报、悄悄下调风险等级、部署防漏扫设备、缩小扫描范围、以工单关闭替代证据留存。  
+  
+因为改善统计口径比改善风险更容易。  
+  
+"漏洞清零"这一个目标为什么会无法达成？在安全威胁日趋严峻、合规考核逐步加强的情况下，有无最佳实践呢？  
+  
+## 一、"漏洞清零"目标存在结构性缺陷  
+  
+  
+### 1.1 漏洞流入速度长期高于处置容量  
+  
+漏洞管理在结构上是一个排队系统，流入速度由外部决定，处置速度由内部资源决定。  
+  
+FIRST 于 2026 年6 月预测CVE漏洞本年将新增 66,000 条，实际披露量较年初预测高出 46.3%。同期漏洞修复指标则反向移动：Verizon 2026 年数据泄露调查报告显示，已知被利用漏洞（KEV）的完全修复比例由上一年的 38% 降至 26%，修复时间由 32 天升至 43 天。  
+  
+在流入加速而处置减速的条件下，漏洞积压的持续增长是结构性结果，与团队投入程度无直接关系。要求积压归零，等价于要求处置速度不低于流入速度，在绝大多数运营者中不具备可实现性。  
+  
+### 1.2 漏洞级别与实际风险的相关性减弱  
+  
+按漏洞级别从高到低逐条清零，会造成修复方向与实际风险的错配：资源被投入到大量永远不会被利用的高级别漏洞上，而正在被攻击者利用的中等级别漏洞排在队列后方。相关组织的研究报告可以说明这一点：  
+  
+**FIRST**  
+（Forum of Incident Response and Security Teams，事件响应与安全团队论坛，全球网络安全事件响应领域的权威国际协调组织）给出三个已被反复验证的观测结果：在全部已发布 CVE漏洞 中，被观测到在野利用的比例长期稳定在 6% 左右；CVSS 7.0 分以上的高危漏洞中，出现实际利用尝试的仅约 2.3%；而在确实被利用的漏洞里，约 28% 的 CVSS 基础分只是中危。  
+  
+**CISA**  
+（美国网络安全与基础设施安全局）在 BOD 26-04（约束性操作指令 26-04：基于风险优先处理安全更新）明确联邦民事行政部门不再使用 CVSS漏洞级别进行优先级排序，而改用实际风险进行排序。  
+  
+可利用性是动态变化的，当时的低可利用性不等于可以永久忽略。可利用性决定的是"何时修"，不是"是否修"，"永不处置"不在合规与运营的选项之内。把低概率项无限期搁置，只是把风险转换成技术债。  
+  
+### 1.3 "清零"固定时限与漏洞利用速度脱节  
+  
+"清零"目标通常配套固定时限，"高危 30 天、中危 90 天"这一类的统一时限，与当前的利用速度已不在同一量级。  
+  
+Google Mandiant 的 M-Trends 2026 将漏洞平均利用时间（TTE）的估计值给为负 7 天，即利用行为通常发生在补丁发布之前，该指标 2018 年为正 63 天，2024 年首次跨过零点。  
+  
+VulnCheck 的统计显示，CVE 漏洞公开至确认进入被利用状态的中位间隔，由 2025 年的 120 天降至 2026 年上半年的 80 天。  
+  
+CrowdStrike 2026 年上半年数据则显示，在已发生的公开漏洞利用事件中，88% 于漏洞披露后 48 小时内发生，零日利用同比增长 42%。  
+  
+对少数真正危险的漏洞，30 天过慢；对绝大多数漏洞，30 天反而构成无谓的紧迫。统一时限模型既无法保护前者，又消耗了处置前者所需的资源。  
+  
+"漏洞清零"天然的结构性缺陷导致了在这一目标下的各类运营管理问题，亟需进行方向性的调整。  
+  
+## 二、AI 使"清零"目标进一步远离可行区间  
+  
+  
+AI 同时改变了漏洞的发现规模、引入速度与利用速度，使清零目标进一步远离可行区间。  
+<table><tbody><tr><th data-colwidth="84" style="background:#0CAD79;color:#fff;padding:10px 12px;text-align:left;font-weight:600;border:1px solid #0CAD79;"><section><span leaf="">维度</span></section></th><th data-colwidth="259" style="background:#0CAD79;color:#fff;padding:10px 12px;text-align:left;font-weight:600;border:1px solid #0CAD79;"><section><span leaf="">变化</span></section></th><th style="background:#0CAD79;color:#fff;padding:10px 12px;text-align:left;font-weight:600;border:1px solid #0CAD79;"><section><span leaf="">事实依据</span></section></th></tr><tr><td data-colwidth="84" style="padding:10px 12px;border:1px solid #ddd;color:#333;vertical-align:top;font-weight:600;white-space:nowrap;"><section><span leaf="">发现规模</span></section></td><td data-colwidth="259" style="padding:10px 12px;border:1px solid #ddd;color:#333;vertical-align:top;"><section><span leaf="">自主发现工具进入披露生态，年度漏洞量级跃升</span></section></td><td style="padding:10px 12px;border:1px solid #ddd;color:#333;vertical-align:top;"><section><span leaf="">CNNVD 收录漏洞 2026 年预计达 7 万条；FIRST 预计 2026 年 CVE 总量接近 66,000 条；DARPA AIxCC 决赛队伍在 4 小时内于 5,400 万行代码中发现 54 个漏洞。</span></section></td></tr><tr><td data-colwidth="84" style="padding:10px 12px;border:1px solid #ddd;color:#333;vertical-align:top;font-weight:600;white-space:nowrap;"><section><span leaf="">引入速度</span></section></td><td data-colwidth="259" style="padding:10px 12px;border:1px solid #ddd;color:#333;vertical-align:top;"><section><span leaf="">AI 生成代码大规模进入生产，缺陷随之规模化引入</span></section></td><td style="padding:10px 12px;border:1px solid #ddd;color:#333;vertical-align:top;"><section><span leaf="">Veracode 2026 年春季测试显示，在未显式给出安全指引时，AI 生成代码的安全通过率约 55%，即约 45% 的情形引入已知安全缺陷，而语法正确率超过 95%。</span></section></td></tr><tr><td data-colwidth="84" style="padding:10px 12px;border:1px solid #ddd;color:#333;vertical-align:top;font-weight:600;white-space:nowrap;"><section><span leaf="">利用速度</span></section></td><td data-colwidth="259" style="padding:10px 12px;border:1px solid #ddd;color:#333;vertical-align:top;"><section><span leaf="">武器化窗口压缩至小时级</span></section></td><td style="padding:10px 12px;border:1px solid #ddd;color:#333;vertical-align:top;"><section><span leaf="">Recorded Future：漏洞武器化中位时间由 72 小时降至 24 小时；Google M-Trends 2026：平均利用时间约为负 7 天。</span></section></td></tr></tbody></table>  
+  
+## 三、最佳实践：风险优先级+例外管理  
+  
+  
+"漏洞清零"运营管理方法应进行调整，把资源集中到少数高风险项并加快其处置，同时为其余部分建立一个正式的、可解释的滞留状态。  
+  
+**风险优先级排序：**  
+结合资产暴露、情报、威胁、合规要求等要素，进行漏洞优先级排序，将资源集中至少数高风险项并加快其处置；  
+  
+**漏洞例外管理：**  
+对在既定时限内不修复的漏洞，通过决策流程将其纳入有评估、有决策、有记录、有期限、有责任人的受控状态。  
+  
+**未纳管例外：**  
+事实上未修复、但没有走过任何决策流程的漏洞。可能存在于电子表格、邮件、工单注释或口头共识中。  
+运营者真正的风险敞口，主要来自未纳管例外。  
+  
+## 四、国外监管合规规则的调研  
+  
+  
+2026 年开始，美国和欧盟相继发布与漏洞管理相关三部强制指令和法规，其合规立场可以概括为：不修复是合法结论，但必须是有据、有期限、可被推翻的结论。  
+  
+**FedRAMP**  
+（Federal Risk and Authorization Management Program（联邦风险与授权管理计划）的缩写，是美国联邦政府为云产品和服务建立的标准化安全评估、授权和持续监控框架。是云安全合格证）于 2026 年 6 月发布的合并规则将"已接受漏洞"设为强制分类，规定评估后 192 天内无法完全缓解或修复的漏洞必须归入该类并附理由上报；  
+  
+**CISA**  
+（美国网络安全与基础设施安全局）在2026年 6 月发布的 BOD 26-04（约束性操作指令 26-04：基于风险优先处理安全更新）撤销了 CVSS 强制排序要求，为最低风险档位给出"随系统升级时修复"这一无期限处置结论；  
+  
+**欧盟《网络韧性法案》（CRA）**  
+附件一将产品投放市场的门槛限定为"不存在已知可利用漏洞"，并以八项漏洞处理流程要求取代对漏洞数量的直接考核。  
+  
+### 4.1 合规对象由数量与状态转向过程与依据  
+  
+FedRAMP 的替代机制为到期强制归类。任何漏洞在评估后 192 天内未被或将不会被完全缓解或修复的，必须归入"已接受漏洞"类别并公开举证。例外的产生不再依赖被监管方主动申请，而由规则自动触发，此前通过反复推迟里程碑日期实现无限期挂账的做法随之终止。  
+  
+### 4.2 未修复漏洞获得了具名的合法类别  
+<table><tbody><tr><th data-colwidth="159" style="background:#0CAD79;color:#fff;padding:10px 12px;text-align:left;font-weight:600;border:1px solid #0CAD79;"><section><span leaf="">规则</span></section></th><th data-colwidth="147" style="background:#0CAD79;color:#fff;padding:10px 12px;text-align:left;font-weight:600;border:1px solid #0CAD79;"><section><span leaf="">例外类别</span></section></th><th style="background:#0CAD79;color:#fff;padding:10px 12px;text-align:left;font-weight:600;border:1px solid #0CAD79;"><section><span leaf="">关键条件</span></section></th></tr><tr><td data-colwidth="159" style="padding:10px 12px;border:1px solid #ddd;color:#333;vertical-align:top;"><section><span leaf="">CISA BOD 26-04</span></section></td><td data-colwidth="147" style="padding:10px 12px;border:1px solid #ddd;color:#333;vertical-align:top;"><section><span leaf="">随系统升级时修复</span></section></td><td style="padding:10px 12px;border:1px solid #ddd;color:#333;vertical-align:top;"><section><span leaf="">四项判据均指向低风险，不设截止日期</span></section></td></tr><tr><td data-colwidth="159" style="padding:10px 12px;border:1px solid #ddd;color:#333;vertical-align:top;"><section><span leaf="">FedRAMP 2026</span></section></td><td data-colwidth="147" style="padding:10px 12px;border:1px solid #ddd;color:#333;vertical-align:top;"><section><span leaf="">已接受漏洞</span></section></td><td style="padding:10px 12px;border:1px solid #ddd;color:#333;vertical-align:top;"><section><span leaf="">评估后 192 天强制归类，须按八项要求举证</span></section></td></tr><tr><td data-colwidth="159" style="padding:10px 12px;border:1px solid #ddd;color:#333;vertical-align:top;"><section><span leaf="">欧盟 CRA</span></section></td><td data-colwidth="147" style="padding:10px 12px;border:1px solid #ddd;color:#333;vertical-align:top;"><section><span leaf="">基本要求不适用</span></section></td><td style="padding:10px 12px;border:1px solid #ddd;color:#333;vertical-align:top;"><section><span leaf="">第 13 条，须在技术文档中给出清晰理由</span></section></td></tr></tbody></table>  
+  
+### 4.4 举证材料由扫描结果转向决策记录  
+  
+FedRAMP要求每一项已接受漏洞报告以下信息：内部跟踪标识、检测时间与来源、评估完成时间、IRV（互联网可达）判定结果、LEV（可能被利用）判定结果、当前 PAIN 评级、列为已接受漏洞的理由说明，以及有助于联邦机构评估或缓解风险的补充信息。  
+  
+CRA 附件七要求技术文档包含漏洞处理流程的必要信息与验证测试报告，保存 10 年或支持期（取较长者）；附件八要求公告机构在模块 B 与模块 H 路径下开展定期审核。  
+  
+两者均围绕互联网可达性、可利用性、影响评级、接受理由与时间戳展开。按最严口径建立一套例外记录，可同时满足多个法域的举证要求。  
+  
+### 4.5 例外设有不可协商的终止条件  
+  
+**欧盟 CRA 第 14 条：**  
+漏洞被主动利用后，24 小时内预警、72 小时内完整通报、纠正措施可用后 14 天内提交最终报告。依据第 69 条的过渡安排，该条适用于 2027 年 12 月 11 日前已投放欧盟市场的存量产品。  
+  
+**FedRAMP：**  
+互联网可达、可能被利用且 PAIN 高于 N3 的漏洞，在缓解至 N3 及以下之前应按可报告安全事件处理。  
+  
+**CISA BOD 26-04：**  
+漏洞进入 KEV 即重新落档，最高档要求 3 天内完成修复并同步开展取证排查，其前提假设是系统可能已被入侵。  
+  
+## 五、漏洞例外管理实施要点  
+  
+  
+### 5.1 漏洞例外管理流程  
+  
+![](https://mmbiz.qpic.cn/mmbiz_png/e1eN8w0qee2p5UibXNmTWd9qqxtgFLlbXMWGeZTwmJNeo0z4dhpcE4uBhhtBYOianPHEb7ovS8U6lngTLpIVJ1DGrWwgRCPV2MK23Vic8GF7rY/640?from=appmsg&watermark=1#imgIndex=0 "")  
+  
+  
+### 5.2 可进入例外的场景  
+  
+01  
+ 技术上不成立（漏洞实际不存在）  
+  
+扫描器误报、调用链不可达、功能未启用、前置条件不满足、平台不适用、上游已反向移植修复。  
+  
+此类严格而言不是接受风险，而是判定无风险，因此不设到期日，只设复核触发条件。但仍须走同一套登记流程，否则将退化为直接标记误报——这是最典型的规避手法。  
+  
+02  
+ 风险已被其他控制覆盖  
+  
+网络隔离、虚拟补丁与 WAF 规则、权限收敛、运行时防护、架构性缓解。需注意完全缓解与部分缓解须明确区分，部分缓解只能降档，不能免除到期日。  
+  
+03  
+ 修复不可得  
+  
+上游补丁未发布、供应商明确不修、闭源设备或固件、EOL 组件无补丁、传递依赖锁定。此类最易形成僵尸例外，须留存持续沟通记录。标记"等待供应商"后不再跟进的，在审计中等同于无记录。  
+  
+04  
+ 修复代价不可接受  
+  
+业务中断风险、兼容性破坏、合约或认证约束、资源冲突。  
+  
+05  
+ 生命周期约束  
+  
+系统已排入退役、重构替换中、临时或短生命周期环境、待迁移的遗留系统。此类的判定要点只有一条：须有已批准的、带日期的计划文件。  
+  
+06  
+ 非漏洞类风险项（延伸适用）  
+  
+配置基线偏离、安全设计偏离、合规控制项缺失。字段结构与漏洞例外一致，可复用同一流程。  
+  
+### 5.3 不适用例外的情形  
+  
+需定义机制的边界，以下情形重要性高于上述场景清单：  
+  
+漏洞已列入合规目录，或存在在野利用证据；  
+  
+公开暴露资产上可自动化利用，且利用后导致完全控制权丢失；  
+  
+存在公开可用的成熟利用代码，且资产互联网可达；  
+  
+无法指定责任人，或责任人不在承担该风险的业务侧；  
+  
+无法给出到期日；  
+  
+理由仅为"资源不足""优先级低"等不指向事实的表述；  
+  
+已进入例外但补偿控制经验证失效。  
+  
+### 5.4 三类常见失效方式  
+  
+01  
+ 审批停留在安全团队内部  
+  
+风险实际由业务侧承担，决策人却不在业务侧，接受行为缺乏授权基础。可按暴露面与影响评级设定三级授权：低风险由安全运营负责人批准并按季度批量复核；中风险由业务系统责任人与安全负责人共同审批；高风险（互联网可达且影响评级高）不进入常规例外通道。  
+  
+02  
+ 例外绑定到漏洞编号而非资产实例  
+  
+同一漏洞在不同资产上的暴露面不同，结论不应统一。绑定到编号将导致新增资产自动继承例外，且暴露面变化不触发重评。  
+  
+03  
+ 接受理由填写模板化文本  
+  
+"资源不足"不构成理由，"该组件未启用且调用链不可达"才构成理由。前者无法通过审计，也无法在威胁情报变化时用于判断结论是否仍然成立。  
+  
+### 5.5 工程化承载是必要条件  
+  
+流程合规将成本从修复动作转移至记录、复核与举证，且该成本持续发生。每一项例外在其存续期内都需维持有效的判定依据。在成规模例外管理上，人工台账无法保证重评及时性，也无法保证证据完整性。承载平台落地至少需要四项能力：  
+  
+与资产管理系统打通，使漏洞例外可绑定到具体实例并随资产变更同步；  
+  
+订阅漏洞情报，实现判据变化的动态触发；  
+  
+与工单系统分离但建立映射，工单反映执行状态，台账反映决策与理由；  
+  
+提供到期提醒、强制决策与审批留痕，杜绝静默展期。  
+  
+## 六、摄星四相"漏洞例外"解决方案  
+  
+  
+摄星四相以资产为锚定、以风险为序、以运营为闭环，在AI漏洞海啸与监管要求收紧的背景下，把漏洞风险治理为可度量、可追溯、可交付的运营成果。  
+  
+摄星四相在例外管理上提供的是从判定、审批、留痕到到期复核的完整通道：每一条暂时不修的漏洞都具备评估、决策、记录、期限与责任人，并在漏洞情报或资产状况变化时被动态调整。  
+  
+01  
+例外绑定资产实例，随资产变更触发重评  
+  
+漏洞例外落在具体资产实例上而非漏洞编号上，新增资产不会自动继承既有例外。平台的状态联动机制会让端口、组件与资产状态的变化自动驱动漏洞状态流转与复活。  
+  
+当一台原本内网隔离的主机出现互联网映射，或此前判定为"功能未启用"的组件重新上线时，原有判据随即失效并重新进入决策流程。暴露面变化不触发重评这一常见失效，由系统自动处理，不再依赖人工定期翻查台账。  
+  
+02  
+情报富化与名单机制驱动结论复核  
+  
+漏洞主数据底座统一多编号口径，持续富化 CVSS 多版本、CWE、EPSS、SSVC、PoC/EXP 与利用成熟度、KEV、APT 与勒索软件关联等维度，标签库将这些特征沉淀为可跨模块复用的结构化条件。  
+  
+红名单用于监管通报、内部专项与高危热点的重点治理。白名单用于业务限制、环境隔离、补丁不可得、风险接受等例外留痕。  
+  
+当某漏洞进入合规目录或出现在野利用证据时，标签与名单的联动可将其从例外池中筛出并重新落档，使"例外可被推翻"具备可执行的触发条件。  
+  
+03  
+决策台账与执行工单分离但保持映射  
+  
+知识底座只做判断与建议，不代替用户改变状态。红白名单面向标准漏洞，不直接改变漏洞状态、不直接派发工单。  
+  
+误报库遵循"预测，不确认"，规则命中后只输出疑似原因、置信度与命中依据，是否置为误报仍由人工或处置流程确认。修复方案库遵循"推荐，不执行"，按条件树命中后输出修复步骤、风险提示与验证方式，但不创建整改任务、不改变漏洞状态。  
+  
+台账记录决策与理由，工单记录执行状态，误报判断与例外说明由个人经验转为结构化可追溯的规则，同时堵住以"标记误报"消化未修复项这一最常见的规避路径。  
+  
+04  
+到期提醒、强制决策与审批留痕  
+  
+工单引擎支持可视化配置 3 至 10 个以上节点的状态机，误报闭环、风险接受、延期与调级都是流程中的正式出口，每一次提出、审批与变更均留痕可审计。  
+  
+公式字段持续计算时效，逼近 SLA 时自动升级并抄送管理层，例外到期不作决策便无法沉默展期。配合 6 种派单策略与漏洞到资产、业务系统、责任人的归属链路，例外审批可按暴露面与影响评级设置分级授权，把决策权交回承担风险的业务侧，避免审批停留在安全团队内部而缺乏授权基础。  
+  
+在举证层面，字段级来源与采集时间的全线溯源加上报告的模板化生成，可将检测时间与来源、评估完成时间、暴露面与可利用性判定、当前评级、接受理由与时间戳沉淀在同一套记录中。按最严口径建立一次，可复用于国内监管通报与 FedRAMP、CRA 等不同方向的举证需求，减少重复整理材料的工作量。  
+  
+  
+  

维度	变化	事实依据
发现规模	自主发现工具进入披露生态，年度漏洞量级跃升	CNNVD 收录漏洞 2026 年预计达 7 万条；FIRST 预计 2026 年 CVE 总量接近 66,000 条；DARPA AIxCC 决赛队伍在 4 小时内于 5,400 万行代码中发现 54 个漏洞。
引入速度	AI 生成代码大规模进入生产，缺陷随之规模化引入	Veracode 2026 年春季测试显示，在未显式给出安全指引时，AI 生成代码的安全通过率约 55%，即约 45% 的情形引入已知安全缺陷，而语法正确率超过 95%。
利用速度	武器化窗口压缩至小时级	Recorded Future：漏洞武器化中位时间由 72 小时降至 24 小时；Google M-Trends 2026：平均利用时间约为负 7 天。
规则	例外类别	关键条件
CISA BOD 26-04	随系统升级时修复	四项判据均指向低风险，不设截止日期
FedRAMP 2026	已接受漏洞	评估后 192 天强制归类，须按八项要求举证
欧盟 CRA	基本要求不适用	第 13 条，须在技术文档中给出清晰理由