速览.

Euro 7 防篡改把网络安全拉进型式批准边界。大部分控制已在 R155 CSMS 中存在——新增的是基于排放的证据视图。

Euro 7 常被视为一项排放法规。这一描述没错,但并不完整。对软件定义汽车而言,合规越来越取决于排放相关的软件、标定值、监控逻辑、环境数据与服务流程在整个生命周期内是否可信。

这使 Euro 7 既是一项排放工程挑战,也是一项防篡改与软件治理挑战。

该法规明确将防篡改、安全与网络安全系统纳入型式批准框架。其实施细则进一步强化了车载监控、车辆环境信息、安全数据交换、耐久性与证据的运行要求。对制造商而言,关键问题不再仅仅是"车辆在测试中是否满足限值?",还包括"我们能否证明影响该结果的软件与参数始终是经过授权、可追溯且受保护的?"

本指南说明 OEM 与供应商如何把 Euro 7 转化为一套工程与治理体系,聚焦于排放相关的软件与数据,而非重复一般的 UNECE R155 或 ISO/SAE 21434 指南。

Euro 7 为何新增一条网络安全工作流

现代排放表现依赖代码与配置。发动机、后处理、电池、制动、能量管理与监控功能都使用可编程逻辑,这些逻辑会在开发、生产、服务,有时还会通过 OTA 更新而变化。一次标定变更可能在不更换任何物理部件的情况下改变排放行为。一次诊断凭据被泄露,就可能让受保护的参数暴露。数据通路的薄弱环节,会削弱呈报给主管机关或用户的信息的可信度。

因此,Euro 7 把保障边界从排气管延伸出来。制造商需要在五个相互关联的领域获得信心:

  1. 安装在车辆上的软件与标定属于该变型的已批准版本。
  2. 受保护参数无法通过未授权的工具、账户或更新通路被更改。
  3. 监控与环境数据真实、完整,并可归属到正确的车辆配置。
  4. 维修与已授权的改装仍然可行,且不会形成不受控的旁路。
  5. 证据能够经受软件更新、供应商变更、服务活动以及车辆长生命周期的考验。

这些要求横跨排放、网络安全、功能安全、诊断、质量、型式批准、法务、售后与供应商管理。把 Euro 7 当作某个合规团队独自拥有的一份文件,会在软件跨越组织边界的关键点上留下缺口。

Euro 7 时间表与规划影响

Regulation (EU) 2024/1257 分阶段适用。自 2026 年 11 月 29 日起适用于 M1 与 N1 新车型,自 2027 年 11 月 29 日起适用于新生产的 M1 与 N1 车辆。重型车与挂车类别自 2028 年 5 月 29 日起适用于新车型,自 2029 年 5 月 29 日起适用于新车辆,小批量制造商另有特别规定。

这些日期已经足够紧迫,以至于架构与证据决策必须在最终的型式批准阶段之前定下。等到型式批准包准备齐全才动手的制造商,可能会发现自己已经无法重建在某次测试时究竟使用了哪份标定、哪个软件版本、哪条诊断访问策略或哪项供应商控制。

一个可落地的规划顺序是:

  • 项目分类:识别受分阶段日期影响的车型、系统、部件与独立技术单元。
  • 资产识别:列出排放相关的软件、标定集、监控功能、数据通道、服务工具、签名密钥与后端。
  • 控制审视:把当前的防护与 Euro 7 防篡改及安全数据要求进行比对。
  • 证据设计:确定在发布、生产、服务、更新与测试时点必须记录哪些内容。
  • 试点:在跨品牌、跨区域铺开之前,先在某一动力总成或电动化平台上验证整体方法。

目标不是再起一套网络安全项目。目标是在组织现有的软件、网络安全与型式批准运行模型之上,增加一层面向排放保障的视图。

什么应被视为排放相关的数字资产?

资产清单过窄是最常见的错误之一。团队往往只列出发动机控制单元就停下。实际的保障链可以包括:

  • 动力总成、后处理、能量管理、热管理、制动与电池控制系统中的可执行软件。
  • 标定文件、MAP、阈值、自适应值、学习参数与诊断例程。
  • 车载诊断与车载监控逻辑。
  • Environmental Vehicle Passport 数据,及用于显示或传输该数据的接口。
  • 软件标识符、变型编码、Bootloader 配置与 Secure Boot 策略。
  • 更新包、清单、签名基础设施、部署审批与回滚控制。
  • 维修工具、工程工具、经销商凭据、服务流程与远程诊断服务。
  • 供应商二进制文件、标定交付物、测试报告与配置声明。
  • 接收、处理、存储或上报监控与耐久性数据的后端服务。
  • 记录"谁在何时、为何、依据哪项审批做了什么变更"的审计日志。

每项资产都需要责任人、权威来源、已批准的变更通路、保留规则,以及与其被使用车辆配置之间的关联。没有这些关系,即便单点上的安全控制再强,也可能因为无人能界定其作用范围而在运行层面失效。

Euro 7 主要的篡改场景

Euro 7 的威胁分析应从可信的业务与工程场景出发,而非一份泛泛的网络攻击清单。

未授权标定修改

攻击者、维修厂、车队运营方或内部人员修改与排放相关的参数,以提升性能、关闭监控、隐藏劣化或回避维修成本。修改可能借助暴露的诊断服务、外泄的工程凭据、克隆工具、有漏洞的 Bootloader 或被篡改的更新包。

监控被压制或被伪造

车载监控被禁用,阈值被修改,故障状态未经授权被清除,或数据在到达显示界面、后端或审批证据包之前被改写。车辆可能继续运行,但其环境状态被错误呈现。

变型与软件不匹配

合法的软件或标定包被安装到了错误的硬件、动力总成、市场变型或 VIN 上。没有恶意修改发生,但配置完整性已经丧失,已批准的排放行为不再适用。

未授权的服务访问

合法的维修能力被滥用。凭据被共用,经销商账户被攻破,访问权限过宽,或服务工具可执行超出技师角色的功能。当同一份凭据可作用于车队的大量车辆时,风险尤其高。

证据链被操纵

测试结果、审批记录、软件标识符或监控数据导出被更改、传输不完整,或被关联到错误的基线。车辆本身可能合规,但制造商无法可靠地证明这一点。

供应商变更未走影响评估

Tier-1 修改软件、标定、库、诊断例程或生产工艺,却未触发 OEM 的 Euro 7 影响评估工作流。变更可能在本地测试中通过,却让车辆级审批用例所依赖的前提失效。

这些场景应按车型与架构分别评估。同一项诊断服务,只通过受控维修工具可达,与可通过远程信息后端访问,其风险大不相同。

围绕授权、完整性与溯源构建控制模型

一套有效的 Euro 7 控制模型,应当比一堆孤立的安全特性更易于审计。围绕五个目标来组织控制。

1. 对每一项敏感操作进行授权

界定哪些主体可以读取、写入、重置、重新刷写、标定或导出排放相关信息。授权应考虑主体、车辆状态、工具身份、位置、目的与目标功能。

良好实践包括最小权限角色、短生命周期凭据、对高影响变更的多方审批、开发与服务权限的分离,以及对生产中不需要的功能进行显式拒绝。

2. 保护软件与参数完整性

使用 Secure Boot、认证更新、代码签名、受保护的标定容器、防回滚措施,以及与系统相称的完整性校验。保护整条通路,而不仅仅是最终固件镜像。如果清单、变型映射、签名工作流或安装决策可被操纵,签名包本身并不能提供保障。

3. 建立可靠的身份与配置

每条测试与运行记录都应可归属到车辆、ECU、软件版本、标定集与相关硬件配置。软件标识必须在更换、服务召回与更新中得以保留。

这正是配置管理与网络安全的交汇点。一个发布基线应是可查询的对象,而不是共享文件夹里的一个文件名。

4. 保留可信的日志与证据

记录安全相关事件,包括参数变更、软件安装、访问尝试、诊断会话、签名验证、监控配置与审批决策。日志应做时间同步、访问受控、防止悄然篡改,并按生命周期要求保留。

证据记录还应包含已授权变更的理由。一项技术上合规、却没有业务依据或审批引用的修改,很难辩护。

5. 检测并响应偏离

明确如何检测未授权或异常状态。检测手段可包括软件远程证明、标定比对、异常诊断行为、无效签名、异常的监控缺口,或车端与后端记录之间的不一致。

响应计划应覆盖遏制、调查、恢复、客户沟通、供应商升级,以及对审批证据的再评估。

在不阻塞合法维修的前提下治理可编程参数

防篡改控制不应让合规的维修变得不可能。这带来一个政策问题:组织必须在众多角色与环境中区分授权变更与未授权操纵。

一种可行的模型是按敏感度对参数与功能进行分级:

  • 公开可读:可在无明显风险的情况下公开的信息。
  • 认证后可读:对已验证的服务或工程角色开放的数据。
  • 受控写入:可在已批准流程下修改的参数。
  • 受限写入:需要更高权限凭据、特定车辆状态与记录在案的授权的高影响变更。
  • 仅工厂或工程使用:在常规服务中被禁用或以密码学方式不可访问的功能。

针对每个等级,明确允许的工具、角色、前置条件、日志、审批与验证要求。使用集中策略,避免品牌与供应商各自定义相互冲突的访问模型。

最棘手的情况是例外:现场维修、监管测试、改装、赛事或特种用途配置,以及紧急服务操作。例外应当被设计,而不是临时凑出来。它们需要时间限制、范围限制、可追溯,以及恢复到已批准状态的流程。

把软件更新挂到 Euro 7 审批用例

任何可能影响排放、能耗、电池耐久性、制动颗粒物、监控或环境信息的软件更新,都应触发结构化的影响评估。

评估应回答:

  1. 哪些功能、参数与车型变型受到影响?
  2. 该更新是否改变了此前已被批准的行为或测试前提?
  3. 是否引入了新的攻击通路或诊断能力?
  4. 哪些验证与确认活动需要重做?
  5. 该更新是否改变了所生成或传输的环境数据?
  6. 部署失败时存在怎样的回滚或恢复通路?
  7. 哪些审批、合规与供应商记录必须随之更新?

更新包应持续与其需求、源代码变更、标定变更、网络安全控制、测试结果、审批以及已部署车辆群保持挂接。这种可追溯性即使在无需正式重新审批时也很有价值,因为它表明组织对已批准配置实施了严格控制。

面向 Euro 7 软件与标定的供应商治理

OEM 的证据强度取决于其背后的供应商信息。合同接口应规定的内容远不止交付日期与校验和。

对于排放相关的交付物,应要求供应商提供:

  • 唯一的软件与标定标识符。
  • 对受保护参数与诊断功能的描述。
  • 变更历史与影响分类。
  • 安全控制的实现证据。
  • 针对防篡改与访问控制要求的验证结果。
  • 已知限制、已接受的偏离与残余风险。
  • 漏洞通报与事件升级承诺。
  • 对现场调查与配置重建的支持。
  • 适用情况下的次级供应商义务。

OEM 还应明确验收标准。供应商声明软件"安全"是不可检验的。一条有用的验收标准会标明控制项、测试方法、预期结果、证据格式、责任人与有效期。

供应商证据应在多个项目间可复用,同时保留项目专属上下文。复用可降本,但盲目复用会掩盖配置差异。平台、硬件版本、特性集与标定范围必须被明确写出。

Euro 7 证据包

一份可辩护的证据包应让评估方能够从一项监管要求逐步追溯到真实的车辆配置及其背后的工程证明。

实用的证据包包括:

  • 范围与车型适用性。
  • 排放相关的数字资产清单。
  • 架构与数据流视图。
  • 聚焦防篡改的威胁与误用场景。
  • 已批准的访问控制与参数治理策略。
  • 软件与标定基线记录。
  • 安全更新与回滚证据。
  • 诊断访问设计与测试结果。
  • 监控、日志与异常检测证据。
  • 供应商声明与验证工件。
  • 变更影响记录与发布审批。
  • 事件、偏离与纠正措施历史。
  • 证据溯源:作者、审核人、日期、版本与来源系统。

证据包不应在审批前才从零拼凑,而应基于当前的工程记录生成。这既能降低审计工作量,也能减少呈现相互矛盾真相版本的风险。

90 天落地路线图

第 1-30 天:确立范围与责任

选择一个车型项目。识别受影响的系统、责任人、供应商、工具与审批节点。建立数字资产清单,并梳理当前的软件、标定、诊断、日志与更新流程。

第 31-60 天:闭合最高风险的缺口

优先处理远程或可规模化的篡改通路、不受限制的参数写入、薄弱的服务身份、无法追溯的标定变更,以及无法关联到发布基线的证据。明确控制要求与供应商行动。

第 61-90 天:跑通证据链

选取一次代表性变更,例如一次标定更新或监控软件修订。从请求开始,依次贯通实现、安全评审、测试、审批、部署与上报,生成 Euro 7 证据视图,不再人工翻找文档。

在试点结束时,组织应清楚知道哪些可以规模化、哪些需要工具集成,以及在排放与网络安全团队之间还需要厘清哪些职责。

证明项目有效的指标

有用的指标关注控制与证据质量,而不是文档数量:

  • 有明确责任人的排放相关软件与参数比例。
  • 已被显式授权策略覆盖的敏感写入功能比例。
  • 具备完整"软件-标定-车辆"可追溯性的发布比例。
  • 为某一 VIN 或变型重建已批准配置所需的时间。
  • 触发书面影响评估的供应商变更比例。
  • 未做过经验证防篡改测试的高影响参数数量。
  • 关键控制项最新证据的存续时长。
  • 从检测到偏离到识别受影响车队的时间。
  • 工程、生产、服务与审批基线之间未解决差异的数量。

仪表盘应允许团队从指标下钻到底层证据。一个没有可追溯记录的"绿色百分比"只会带来虚假的信心。

互联证据模型如何提供帮助

Euro 7 形成了电子表格难以承载的关系:软件归属于 ECU;一个 ECU 装在多个变型上;一个参数影响一项功能;一项控制保护该参数;一项测试验证该控制;一次发布修改了软件;一家供应商拥有部分实现;一份审批记录适用于特定基线。

互联的网络安全与合规模型,使这些关系变得可查询。团队可以追问:哪些车型使用了某份标定,哪些控制项保护它,哪些测试仍然有效,哪些发布修改过它。ThreatZ 可以支持这种运行模式,把架构、风险、控制、测试、供应商、软件记录、事件与报告关联起来,而不是另建一个独立的 Euro 7 文档孤岛。

一个可行的起点是一套排放相关系统加一条真实的变更工作流。目标是从工程到现场运行,展示可信的配置与证据。

常见问题

Euro 7 是一项网络安全法规吗?

Euro 7 是一项排放与车辆耐久性法规,但明确将防篡改、安全与网络安全系统纳入其中。对于受软件控制的排放行为,网络安全控制成为制造商保护可编程参数、监控、数据与审批完整性的方式之一。

符合 UNECE R155 是否自动满足 Euro 7 防篡改要求?

不会。R155 提供了重要的网络安全管理基础,但 Euro 7 具有不同的监管目的与证据上下文。组织应复用治理、威胁分析、访问控制、安全更新与监控能力,同时建立面向排放的适用性与保障视图。

哪些团队应负责 Euro 7 软件防篡改?

责任应通过明确的治理模型共享。排放或型式批准团队对监管合规负总责;网络安全、软件、标定、诊断、售后、质量与供应商团队则负责各自的控制项与证据。

每个标定参数都需要同等保护吗?

不需要。采用基于风险的分级。会实质性影响受监管行为、监控、安全或证据完整性的参数,需要更强的授权、日志与验证;而低影响或只读信息则不必。

最适合作为首个试点的对象是什么?

选择一套具备可编程排放相关参数、多家供应商,以及现实存在的服务或更新通路的系统。端到端跟踪一次已批准变更,检验当前组织能否证明谁授权了它、安装了什么、如何验证,以及部署到了哪里。

权威参考

  • Regulation (EU) 2024/1257 - Euro 7
  • EUR-Lex 关于 Euro 7 技术要求与认证的摘要
  • Commission Implementing Regulation (EU) 2025/1706

VxLabs 相关延伸阅读