如果您计划将新车销往中国市场，您需要证明产品符合 GB 44495——中国汽车信息安全的强制性国家标准。该标准由国家标准化管理委员会（SAC）于 2024 年发布，并由工业和信息化部（MIIT，简称工信部）通过 2026—2028 年的型式批准要求逐步纳入实施。提交前，请务必依据最新的 MIIT 车辆产品公告核实当前生效日期——具体时间表通过 MIIT 公告发布，而非标准文本本身规定。

如果您已在欧盟、日本或韩国按 UNECE R155 合规，GB 44495 表面上看起来类似——两者都要求组织级的网络安全管理体系（CSMS）、车型级的威胁分析与风险评估（TARA），以及持续的产品后监测。两个标准明确借鉴了同一智识谱系：WP.29 R155 + ISO/SAE 21434。

差异在细节里——威胁目录、证据格式、被认可的检测机构、数据驻留要求、中国 MIIT 车辆产品准入流程，以及上市后报告义务。本文梳理一家拥有成熟 R155 合规体系的整车厂在进入或扩大中国市场时，必须重做什么、可以复用什么、以及应当事先规划什么。

速览（给没空细看的人）

  • GB 44495 是中国汽车信息安全强制性国家标准。通过 MIIT 型式批准在 2026—2028 年逐步生效；具体生效日期由 MIIT 公告确定，而非标准文本——每次提交前请核实。
  • 它在结构上与 R155 + ISO/SAE 21434 对齐，但并不等同。两者之间没有互认；获得欧盟型式批准的车辆仍需通过中国独立的评估。
  • CSMS 流程文档大部分可复用；TARA 工件大部分可复用；威胁目录映射需要中国语境的覆盖层；证据包需要以中文重新呈现，并提交至中国汽车技术研究中心（CATARC）或其他 MIIT 指定机构。
  • 对于已具备成熟 R155 证据的整车厂，首个车型的增量工作量通常为 3—6 个月；建立中英双语证据流水线后，后续车型可降至 4—8 周。
  • 最大的实际风险是数据驻留（PIPL + CSL + DSL 三法叠加于 GB 44495 之上）、OTA 基础设施合规，以及对中国本土 SBOM／漏洞数据库的依赖，而非仅依赖 NVD。
关于本指南。

本文反映已发布的 GB 44495 文本、截至 2026 年第一季度的 MIIT 实施通知，以及 CATARC 关于型式批准网络安全评估的公开指南。中国监管环境演进迅速；请将日期与流程细节视为截至 2026 年 4 月的权威信息，并在提交型式批准前依据最新 MIIT 公告核实。我们会在重大变更发布后更新本页。

速览对照表

维度 UNECE R155 GB 44495
法律依据 UNECE 1958 协定；欧盟通过法规 2019/2144 落地 MIIT 型式批准下的国家标准（强制性）；交叉引用网络安全法（CSL）、数据安全法（DSL）、个人信息保护法（PIPL）
地理范围 欧盟 + 英国 + 日本 + 韩国 + 60 余个 UNECE 1958 缔约方 中华人民共和国（大陆）
车辆范围 类别 M、N、O 中至少含一个 ECU 的车辆 M 类（乘用车）、N1 类（轻型商用车）；其他类别分阶段纳入
生效日期 新车型 2022-07；所有新车 2024-07 分阶段纳入 MIIT 型式批准 2026—2028；以最新 MIIT 公告为准
CSMS 要求 强制性 CSMS 证书，有效期 3 年 强制性网络安全管理流程，作为型式批准的一部分被审查（无独立证书）
TARA 要求 按 R155 附件 5 威胁清单做车型级 TARA 按 GB 44495 第 5 章 + 附录 A 威胁目录做车型级风险评估
批准机构 国家型式批准机关 + 指定技术服务机构（如德国 KBA、荷兰 RDW） MIIT 指定机构，主要为 CATARC；获批后进入 MIIT 车辆产品公告目录
威胁目录 R155 附件 5（7 个攻击类别下约 32 项高层级威胁，含相关脆弱性与缓解措施） GB 44495 附录 A（结构上与 R155 大体对齐但已重组；新增中国语境下的威胁，如本土定位系统相关风险）
SBOM 未明确强制；ISO/SAE 21434 建议进行软件标识 SBOM 通常作为证据要求；格式参考 SAC/TC260 下的中国国家标准
事件报告 需通知型式批准机关，无固定时限 向 MIIT 报告；涉及个人信息的须通报国家互联网信息办公室（CAC）；与 PIPL/DSL 报告窗口（通常 24—72 小时）协调
上市后义务 整车寿命周期内的监测与更新 监测 + 更新 + 中国境内漏洞数据库登记；OTA 基础设施须符合中国独立的 OTA 标准
证据语言 视主管机关而定；通常接受英文 中文为主；可接受中英双语技术文件，但中文版本为控制版
与 R155 互认 不适用 无正式互认；评估机构可酌情接受部分证据复用
不合规处罚 撤销型式批准；车辆不得在欧盟销售 拒绝型式批准；从 MIIT 车辆产品公告目录中移除；车辆不得在中国销售

GB 44495 实际要求什么

GB 44495（标准全称：《汽车信息安全通用技术要求》）围绕整车厂必须向评估机构展示的三项主要交付物展开：

1. 制造商层面的网络安全管理流程

整车厂必须证明其网络安全由文档化的流程治理，覆盖概念、开发、生产、上市后监测、以及支持终止阶段。流程必须定义角色、职责、培训、供应商管理，以及网络安全相关决策的变更控制流。本质上等同于 R155 中的 CSMS。

与 R155 在实践中的两点差异：

  • GB 44495 不单独颁发 “CSMS 证书”。网络安全管理是作为车辆型式批准的一部分被审计的，不是另一份具有 3 年有效期的组织级证书。
  • 评估机构期望看到本土供应商治理的证据——若您的一级供应商位于欧盟，您必须证明他们的网络安全活动是如何在中国型式批准框架下被协调的，包括任何涉及 PIPL 或 DSL 的数据交接安排。

2. 车型级风险评估

对每一个申报型式批准的车型，整车厂必须提交一份 TARA，其中：

  • 识别车辆中网络安全相关的资产。
  • 以 GB 44495 附录 A 目录为基线枚举威胁场景。
  • 评定影响与可行性，计算风险，并定义缓解措施。
  • 证明残余风险对预期使用是可接受的。

附录 A 的威胁目录与 R155 附件 5 大体对齐，但被重新组织为中文类别。少数类别在中国语境下要求更严或框架不同：尤其是本土定位与导航系统（北斗）、蜂窝车联网（C-V2X）而非 DSRC、以及反映 CSL/DSL 约束的数据出境路径等相关威胁。

如果您的 TARA 已按 ISO/SAE 21434 第 15 章组织，那么 GB 44495 TARA 主要是一次重映射工作，而不是重新撰写。威胁 ID 变了、语言变了，但分析结构相同。

3. 已落实的控制措施与证据包

整车厂必须证明风险处置决策已落实并经过验证。证据以中文技术文件形式提交至评估机构，通常包括：

  • 架构文档（电子电气架构、信任边界、关键接口）。
  • 软件清单（SBOM）及与已知漏洞的映射。
  • 漏洞处置流程，含 CNNVD/CNVD 数据库集成。
  • 安全更新机制文档，证明符合 GB 44495 引用的汽车 OTA 标准。
  • 安全控制的测试报告（渗透测试、模糊测试、集成测试）。
  • 包含具体 MIIT/CAC 报告流的事件响应预案。
  • 内部审计与供应商评估记录。

哪些可以与 R155 共享

如果您已具备成熟的 R155 证据，可复用部分比预想的更多。

流程文档：~80—90% 可复用

您的 CSMS 政策、培训记录、内部审计程序、供应商管理框架、事件响应预案，经翻译后可直接迁移。评估机构关注同样的管理体系属性；只有少数章节需要新增（PIPL/DSL 接触面、本土代表、本土供应商治理）。

TARA 结构：~70—80% 可复用

资产定义、攻击可行性评分规则、威胁枚举逻辑、风险处置决策可直接迁移。工作量在于重新映射威胁场景——把 R155 附件 5 的 ID 映射到 GB 44495 附录 A 的 ID——以及新增 R155 未列出的中国语境威胁（例如具体的北斗欺骗场景、C-V2X 特有攻击、受 DSL 影响的数据出境路径）。

如果您的 TARA 平台支持多标准目录覆盖层，这是数小时的工作而不是数周。如果您的 TARA 还在 Excel 里，请为每个车型预留若干工程师周来手工重映射。

测试证据：~60—70% 可复用

渗透测试、模糊测试、集成测试报告在实质上可复用，但通常需要新的封面、中文执行摘要，以及（在某些情况下）针对中国特有协议（北斗、C-V2X、GB 强制要求的 SM2/SM3/SM4 国密算法等，视车型而定）的补充测试。

SBOM：~95% 可复用，主要是格式工作

如果您的 SBOM 是 CycloneDX 或 SPDX 格式，底层清单可复用。中国评估机构日益期望漏洞关联除 NVD/MITRE 外，还参考 CNNVD（中国国家信息安全漏洞库，由 CNITSEC 运营）和 CNVD（国家信息安全漏洞共享平台，由国家互联网应急中心 CNCERT/CC 运营；其子库 CNVD-ICS 专门覆盖工业控制系统）。针对这些库重新运行 CVE 关联是一个自动化步骤，而非手工重写。

哪些需要实质性变更

有五件事需要新工作，而不只是翻译。

1. 型式批准机构与提交流程

R155 证据提交给您所在国的型式批准机关（德国 KBA、荷兰 RDW 等），由其颁发在所有缔约方有效的批准。GB 44495 证据提交给 MIIT 指定的中国机构——实际上 CATARC（中国汽车技术研究中心）承担大多数网络安全评估——批准仅在中国大陆有效。欧盟证书没有自动跨境承认。

这里的行政工作量不在技术 TARA 本身，而在于建立本土代表关系、为中文受控源文件设立文件控制流程、以及符合 DSL 数据出境规则的证据交接安全通道。

2. 数据驻留与 PIPL/CSL/DSL 三法叠加

这是欧洲整车厂遇到的最大实际意外。GB 44495 本身并未直接施加数据驻留要求，但它运行在一个监管栈中，任何处理个人数据、车辆遥测数据或重要数据的网络安全活动都必须符合：

  • PIPL（个人信息保护法）针对个人数据——包括驾驶员、乘员以及联网账户信息。
  • CSL（网络安全法）针对 “关键信息基础设施” 的认定——某些整车厂的云后端可能落入范围。
  • DSL（数据安全法）针对重要数据与核心数据分类。

实际效果：如果您的上市后监测把遥测、攻击指示器或车辆健康数据从中国大陆传输到您的全球 SOC，您必须证明该数据流已通过 CAC（国家互联网信息办公室）跨境数据安全评估，或落入许可的例外情形，或已匿名化到不再属于 PIPL 监管的个人数据范畴。

这并不是 GB 44495 新创设的要求；而是既有的 PIPL/CSL/DSL 栈，因 GB 44495 强制要求的网络安全活动而具有了实操相关性。许多整车厂直到他们的 CSMS 证据包因为漏洞监测程序在未取得合规跨境传输机制下把数据路由到非中国 SOC 而被拒，才发现这一点。

3. OTA 基础设施合规

R155 引用与之相关的 UNECE R156 进行软件更新管理；GB 44495 之上是中国独立的 OTA 监管框架，操作性文件为 MIIT 2022 年发布的汽车 OTA 备案通知（工信厅装函〔2022〕95 号），并由若干 GB/T 系列推荐性国家标准支持。所要求的实质性控制——签名更新、回滚保护、完整性校验、失效安全行为——与 R156 类似。程序性要求（OTA 升级活动 MIIT 备案、通知窗口、证据留存）则不同。在设计 OTA 证据流水线之前请核实当前 GB/T 编号与 MIIT 备案模板；该标准集正在持续修订中。

如果您的 OTA 架构符合 R156，技术控制可以迁移。通知 + 日志 + 证据留存层需要中国本土的实现：时间窗口须与 CSL 的事件报告期望对齐，日志须可应 MIIT 要求被调取。

4. 漏洞数据库与披露流程

R155 期望企业建立漏洞监测程序，但未规定具体数据库。中国评估方日益期望企业除 NVD/MITRE 之外，监测覆盖 CNNVD 与 CNVD。这些库会发布 NVD 未收录的漏洞，主要针对中国本土开发的组件以及国内分发的开源分支。

披露流程也不同。R155 倾向通过型式批准机关进行协同披露。GB 44495 期望与 CNVD（或针对工控漏洞的 CNVD-ICS）协调，并就影响整车保有量的事件向 MIIT 报告，若涉及 PIPL 范围的个人数据则需同时向 CAC 报告。要建立一个能同时满足三套有交叠的报告窗口的清晰协同流程，需要专门设计；它通常不是欧盟披露 SOP 的简单拷贝。

5. 本土供应商治理

如果您的中国车型使用了中国境内的一级或二级供应商（HMI、信息娱乐、部分 ADAS 子系统、以及越来越多的电动车电池管理系统都是典型场景），整车厂必须证明这些供应商在同一套网络安全管理流程下受治理。供应商接口协议通常需要按中文重新签订，并对齐评估机构的期望。

最干净的路径是复用您已为欧洲一级供应商建立的供应商网络安全问卷结构，进行翻译，并补充覆盖 DSL/PIPL 接触点、本土漏洞披露、以及 CNNVD 订阅的具体条款。

整车厂中国市场进入实操清单

以这份清单作为合理性自检——它不是替代合格本土代表与评估机构沟通的方案。

首次中国型式批准前 12 个月

  1. 确认您在中国大陆的本土代表，并定义网络安全决策接口。
  2. 与 CATARC（或您指定的评估机构）开展申请前预沟通——预算 1—2 轮。
  3. 启动 CSMS 流程文档的中文技术翻译（首版预留 2—3 个月加内部评审时间）。
  4. 把 R155 附件 5 威胁目录映射到 GB 44495 附录 A，识别需要补入 TARA 模板的中国语境威胁。
  5. 对照 PIPL/CSL/DSL 复核您的数据流架构。如果监测平台从中国出境数据，提前规划跨境传输机制。

提前 6 个月

  1. 使用 GB 44495 目录对您的中国车型进行完整 TARA，并由中文流利的评审人验证。
  2. 在现有 NVD 流水线之外建立 CNNVD/CNVD 漏洞监测。
  3. 对照中国 OTA 标准栈验证您的 OTA 基础设施——尤其是日志、留存、以及 MIIT 可访问性。
  4. 为中国一级供应商重新签订接口协议。

提前 3 个月

  1. 使用 GB 44495 + CSL/PIPL/DSL 接触点准则进行最终内部审计。
  2. 整理中文证据包。
  3. 用接近真实的时间窗口对 MIIT + CAC + CNVD 报告流做一次桌面式应急演练。
  4. 向 CATARC 提交预评估包，进行非正式审阅。

提交与获批后

  1. 正式提交型式批准网络安全包。
  2. 响应评估方问询（典型 2—4 轮）。
  3. 批准后，配置针对 CNNVD/CNVD 的持续监测，并把告警接入 CSMS。
  4. 建立与 MIIT 的季度报告节奏，提供整车保有量层面的漏洞数据；具体节奏因车型而异，在批准过程中确定。

常见陷阱

把 GB 44495 当作 “中文版 R155”

两个标准是对齐而非等同。完全照搬欧盟证据——不重映射威胁目录、不增加本土供应商条款、不针对 PIPL/CSL/DSL 验证数据流——经常会导致评估方反复退回甚至直接拒绝。增量是真实存在的，即使它是渐进的。

低估数据流审查

许多整车厂直到周期后期才发现，他们的全球 SOC、威胁情报平台或遥测后端从 CSL 或 DSL 角度并不合规。在型式批准进行中重构遥测路由代价昂贵。请在 12 个月预留期阶段就审计数据流。

TARA 没有中文流利的评审人

附录 A 的威胁 ID 不是 R155 附件 5 ID 的简单翻译。类别的细微重组意味着仅靠英文评审的 TARA 可能 “ID 完整” 但漏掉评估方会问到的中国语境场景。提交前请由中文流利的评审人进行验证。

忘记 OTA 日志规范

符合 R156 的 OTA 架构常常忽略 MIIT 可访问的日志层，直到评估方提出要求。请规划日志留存，按 VIN 与软件版本可索引，并配套用于 MIIT 查询的文档化流程。

如何与 ISO/SAE 21434 对齐，做单源 TARA

R155 与 GB 44495 都引用或对齐 ISO/SAE 21434。如果您的 TARA 工作流按 ISO/SAE 21434 的第 9 章（概念）、第 10 章（产品开发）、第 15 章（TARA）组织，您可以做一次单源 TARA，其输出同时渲染为 R155 附件 5 映射与 GB 44495 附录 A 映射。

平台层面的模式如下：

  1. 在工具中按 ISO/SAE 21434 撰写 TARA。
  2. 维护一个目录覆盖层，把 ISO 21434 威胁场景转换为 R155 附件 5 与 GB 44495 附录 A 的 ID。
  3. 从同一个源 TARA 通过模板生成区域证据包（R155 与 GB 44495）。
  4. 跟踪不同目录版本之间的差异，使得当 GB 44495 修订（预计每两年一次）时，只需复审差异部分。

当一款自动化 TARA 平台原生集成多标准目录覆盖层时，它就为您完成了上述工作。手工执行这种重映射是可行的，但很容易在整车厂提交给 KBA 与提交给 CATARC 的内容之间产生不一致。

ThreatZ 如何支持 GB 44495 合规。

ThreatZ 内置 GB 44495 附录 A 威胁目录，与 R155 附件 5、ISO/SAE 21434 目录在同一个覆盖层中映射。一次撰写 TARA，从同源生成中文或英文证据包。CNNVD 与 CNVD 与 NVD 一起接入 SBOM × CVE 关联流水线。了解 ThreatZ 如何支持多标准 TARA →

关键要点

  1. GB 44495 正在通过 MIIT 车辆型式批准分阶段实施；具体生效日期由 MIIT 公告确定，而非标准文本——每次提交前请核实最新公告。它与 R155 之间没有互认。
  2. 如果您具备成熟的 R155 + ISO/SAE 21434 证据，CSMS 流程文档与 TARA 结构大约可复用 70—90%。增量在于重映射威胁目录、翻译为中文、并补入中国语境元素。
  3. 最大的实际风险是数据驻留（PIPL/CSL/DSL 叠加于 GB 44495 之上）、OTA 日志合规，以及漏洞数据库覆盖（除 NVD 外，CNNVD/CNVD）。
  4. 为首个中国车型的型式批准预留12 个月跑道；建立中英双语证据流水线后，每个后续车型可降至 4—8 周。
  5. 尽早对接 CATARC（或您指定的评估机构），确保本土代表，并在提交前建立中文流利的技术评审能力。不要冷启动提交。

延伸阅读