UN R157 最初将 ALKS 限制在乘用车 60 km/h；01 系列修订把限速提到 130 km/h 并支持变道，且适用范围扩展到重型车辆。R157 是一个移动靶。
自动驾驶网络安全不能被简化为"保护某个 ECU 免遭远程入侵"。自动驾驶系统（ADS）的决策来自传感器、地图、定位、机器学习模型、车辆控制、云服务、远程辅助工作流与车队反馈。安全目标不只是阻止未授权访问，而是要在运行设计域（ODD）内保持安全、可预测的行为，并在现实与预期发生偏离时能够证明发生了什么。
这种证明正变得更加重要。NHTSA 的常设通用命令要求被列名的制造商与运营方报告涉及 ADS 或 L2 系统的合格碰撞，为该机构的调查与执法提供真实世界信息。UN R157 把自动驾驶审批与网络安全、软件更新要求绑定。运行证据、软件配置、事件数据与变更控制现已成为核心的保证资产。
本指南阐述如何把网络安全植入 ADS 与 Robotaxi 车队的运行级保证模型。聚焦于网络风险、安全行为、远程运营、机器学习与现场证据之间独有的相互作用，而非重复一份通用的联网车安全方案。
把系统边界画到车外
ADS 是一个社会技术系统。保证边界可能包括：
- 车内传感器、计算平台、网络、执行器与电源系统。
- 感知、预测、规划、定位与控制软件。
- 机器学习模型及其训练与验证数据。
- 高精地图、定位修正、天气、交通与施工数据。
- 车队管理、调度、遥测、日志与更新服务。
- 远程辅助或远程运营中心。
- 云仿真与验证流水线。
- 移动应用与客户身份。
- 车场、充电、维护与标定系统。
- 第三方服务与通信网络。
- 人员操作员、安全员、支持人员与现场技师。
源自非驾驶服务的威胁仍可能影响驾驶行为。被污染的地图源会扭曲定位；远程辅助账号会暴露运营决策；车场工具能修改传感器标定；错误的车队配置可能让软件在已批准条件之外被激活。
架构必须展示数据流与权限流，而不只是组件。请问：哪些来源能影响决策？哪些系统能指挥车辆？哪些人能否决、建议或批准动作？
把安全与运行设计域绑定
运行设计域（ODD）定义 ADS 拟运行的条件，可能包含道路类型、地理范围、车速、天气、光照、交通、施工、连通性及其他约束。
网络安全可能通过多种方式削弱 ODD 的执行：
- 篡改位置或地图数据，使车辆相信自己处于允许区域内。
- 更改天气、路况或基础设施输入。
- 更改控制激活的配置阈值。
- 抑制健康或退化信号。
- 破坏车队对路径或服务区域的授权。
- 重放历史上的有效状态。
- 在未更新已批准 ODD 用例的情况下修改软件或模型版本。
把 ODD 条件作为安全相关资产对待。定义可信来源、校验逻辑、交叉核验、新鲜度要求，以及输入冲突时的安全行为。
一个有用的保证查询是："对这次行程，有哪些证据表明该车在每一相关时刻都获得授权、配置正确并在已批准 ODD 范围内运行？"
保护"传感器到决策"链路
ADS 安全需要从物理输入到车辆动作的可追溯性。
传感器与接口
摄像头、雷达、激光雷达、GNSS、惯导、超声波传感器与车辆状态输入可能被欺骗、致盲、遮挡、误标定、重放或断连。物理攻击与网络攻击经常重叠。
控制包括输入可信度检查、传感器多样性、必要时对车内通信进行认证、标定完整性、健康监控、防篡改检测与优雅降级。
感知与融合
畸形数据可利用解析器，或为机器学习模型制造对抗条件。融合逻辑应能检测不一致来源，而非放大某一被入侵输入。
定位与地图
地图数据、修正与地理围栏需要源真实性、版本控制、更新完整性与新鲜度。车辆应对照实时观察验证地图预期，且不应在缺乏回退手段时把云可用性视为安全要求。
规划与控制
保护承载轨迹、约束与执行器命令的接口。设置边界与独立安全监控器，使任一受损软件组件都无法发出无约束的控制。
日志
记录足以重建决策的状态，但不要把日志变成新的隐私或安全漏洞。时间同步与配置标识至关重要。
安全控制应在每一层与端到端路径上分别测试。安全的传感器驱动并不能证明端到端决策是有韧性的。
保护机器学习资产与流水线
ML 模型只是更大供应链中的一部分。重要资产包括训练数据、标签、特征流水线、模型权重、评估数据集、仿真场景、构建环境、注册中心、部署清单与监控阈值。
威胁包括：
- 被投毒或质量低劣的训练数据。
- 对标签或场景的未授权变更。
- 模型被盗或被替换。
- 被入侵的依赖与构建工具。
- 评估泄漏或刷分。
- 对抗性输入。
- 被忽视或被隐藏的漂移。
- 把错误模型部署到错误的车辆变体。
- 研究与生产环境隔离不足。
控制应建立：
- 数据集来源与访问控制。
- 版本化的模型与数据血缘。
- 签名产物与受控注册中心。
- 可复现的训练与评估。
- 独立的验证数据集。
- 部署审批关卡。
- 变体与硬件兼容性。
- 针对漂移与异常行为的监测。
- 回滚与隔离。
- 从模型变更到受影响场景与车辆的可追溯性。
不要因为模型通过了一组固定的对抗测试集就声称它"安全"。威胁会演化，且运行条件可能与实验室假设不同。
远程辅助是一种特权接口
Robotaxi 与 ADS 车队在车辆遭遇异常情况时可能使用远程辅助。人可以提供上下文、从备选项中选择、批准某个机动，或在部分设计中施加更直接的影响。
该接口应享有与安全关键控制系统同等的严谨度。
请明确：
- 远程操作员的确切权限。
- 操作员是建议、授权，还是直接控制。
- 允许使用辅助的条件。
- 车辆与会话认证。
- 操作员身份、资质与位置。
- 强身份认证与特权访问管理。
- 命令或建议的完整性与新鲜度。
- 延迟、连通性与链路丢失行为。
- 录制、复审与隐私。
- 职责分离与主管升级。
- 每位操作员可负责的车辆上限。
- 紧急与被入侵情形的处置流程。
被入侵的远程辅助账户可造成规模化危害。请采用最小权限、设备态势、网络分段、会话录制、行为监测与快速吊销。
车辆应保留对安全约束的最终责任。仅因来自已认证操作员，远程指令不应能绕过独立的边界限制。
车队与调度安全
车队系统决定车辆在何处运行、使用哪些软件与配置、如何路由，以及何时进入或退出服务。这些系统的后果可与车内代码同等重大。
请保护：
- 车辆登记与身份。
- 调度与路径分配。
- 地理围栏与服务区域配置。
- 维护与发布状态。
- 远程停用或恢复功能。
- 充电与车场运营。
- 客户接驾与身份匹配。
- 全车队特性开关。
- 批量动作与活动管理。
批量管理动作应比单车动作要求更强审批。采用分阶段灰度、分组上限、变更窗口、同行评审与自动回滚标准。
对运营多个项目或合作伙伴的运营方，租户与区域隔离很重要。某城市的支持用户不应通过修改对象 ID 就能访问到另一支车队。
软件与配置变更控制
ADS 行为可能通过代码、模型、地图、阈值、策略、传感器标定、基础设施或后端逻辑发生变化。保证流程必须把它们全部识别为配置。
对每次变更，请确定：
- 哪些功能与安全/网络安全声明受影响？
- 哪些 ODD 条件或场景需要重新评估？
- 哪些车辆与硬件变体兼容？
- 必须重做哪些测试？
- 该变更是否改变远程辅助或车队行为？
- 适用哪些监测与回滚标准？
- 必须更新哪些监管或报告记录？
使用不可变的发布基线，标识完整部署配置，而不仅是主软件版本。要重建一次事件可能需要地图、模型、标定、策略与云服务版本。
分阶段部署变更。金丝雀车辆与影子模式评估能降低风险，但需要明确的成功与停止条件。若遥测或场景覆盖不完整，"没有观察到事件"并非充分证据。
把运行证据当作一种安全控制
上线前测试无法覆盖每一种真实交互。运行证据有助于判断控制是否仍然有效、是否出现新风险。
有用的证据包括：
- ODD 进入与退出事件。
- 传感器与子系统健康。
- 脱离与最小风险机动。
- 远程辅助请求与结果。
- 安全监控器干预。
- 安全告警与认证事件。
- 软件、模型、地图与配置标识。
- 碰撞与险情上下文。
- 异常路线或行为聚类。
- 更新与回滚历史。
- 操作员与维护动作。
目标不是"什么都采集"。先定义证据需要支持的决策，再采集所需的最少可信数据。
保留来源、时间同步、访问控制与保留策略。缺乏已知配置或时钟完整性的日志在调查中可能不可用。
NHTSA 的碰撞报告框架展示了真实世界数据一致性所具备的监管价值。即便某起事件不属于必报范围，同样的纪律也能改善内部学习与缺陷检出。
网络-安全联合事件分诊
ADS 事件可能涉及软件、网络安全、安全、运营、人为或环境原因。分诊应避免过早把它装进单一类别。
建立一个联合流程，涵盖网络安全、安全、ADS 工程、车队运营、法律、质量与传播。初始问题包括：
- ADS 或相关辅助是否处于激活状态？
- 车辆是否位于拟定的 ODD 内？
- 部署了哪些软件与配置？
- 是否出现认证、完整性或安全异常？
- 传感器、地图或云输入是否相互矛盾？
- 是否涉及远程辅助？
- 近期变更是否在相似事件中具有共性？
- 恶意行为者能否复现或规模化该行为？
- 哪些车辆共用受影响组件或配置？
- 哪种遏制动作是安全的？
恢复过程中不要覆盖证据。尽可能保留日志、易失状态、云轨迹、操作员记录、更新历史与相关外部数据。
遏制选项可能包括路线限制、ODD 缩减、功能停用、凭据吊销、配置回滚、增强监控、车场召回或车队暂停。最安全的响应取决于上下文。
ADS 运营特有的威胁场景
ODD 边界操纵
通过伪造位置、地图、天气或车队授权数据，诱导车辆在 ADS 未获批准的范围内运行。
远程辅助被入侵
攻击者冒充操作员、篡改建议、重放会话，或对多辆车获得过度控制。
模型或配置不匹配
把有效但不兼容的模型、地图、标定或策略部署到错误的硬件或服务区域。
车队范围特性滥用
特权后端账户跨大量车辆变更行为、地理围栏或安全设置。
传感器退化隐瞒
健康指示被抑制或被操纵，使车辆在感知受损的情况下仍处于自动驾驶服务中。
通过运营反馈实施数据投毒
恶意或受损的车队数据进入训练、仿真或验证流水线，并影响未来 Release。
对抗性基础设施交互
被入侵的路侧、施工、地图或通信信息导致非预期的规划行为。
证据被篡改
日志、事件时间、配置记录或操作员动作被修改，妨碍准确的调查与报告。
每个场景都应关联到控制、测试、监控与安全响应。
验证策略
ADS 网络安全验证应结合多种方法。
架构与攻击路径分析
追踪外部服务、操作员、传感器、车场系统与云账号到驾驶决策与执行器的路径。
组件测试
对解析器进行模糊测试、测试认证、评估安全启动、检查密钥存储、验证故障处理。
仿真
大规模运行受网络影响的场景：定位欺骗、传感器不一致、恶意地图更新、远程辅助延迟与异常车队命令。
SIL 与 HIL 测试
在畸形输入、时序故障、网络操纵、传感器退化与控制边界条件下验证软硬件行为。
封闭场地测试
在受控对抗条件下验证物理后果与安全回退。
运行影子评估
在不控制车辆的前提下，把新模型或策略与现实条件对照，受隐私与安全控制约束。
红队演练
测试整个组织，包括云、操作员、支持、供应商、车场与事件响应。
每一项测试结果都应标识配置、场景、预期行为、观测结果与所关联的保证声明。
供应商与合作方保证
ADS 依赖传感器、计算、地图、连通性、仿真、远程运营、云平台以及众多软件供应商。请定义网络安全接口协议，覆盖：
- 资产与责任边界。
- 软件与模型来源。
- 漏洞通报。
- 变更与发布通知。
- 事件证据与支持。
- 访问与远程管理。
- 安全测试证据。
- 运行监测。
- 数据保留与共享。
- 支持终止与过渡。
供应商的组件级证据应可复用，但 ADS 集成方仍对车辆与运行上下文负责。一个安全的传感器并不能证明感知系统能处理协同欺骗场景。
治理指标
追踪以下指标：
- 具有完整配置标识的在役车辆占比。
- 具备完整审计证据的特权远程辅助会话占比。
- 识别共享受影响模型、地图或软件版本之车辆所需时长。
- 完成场景与 ODD 影响评估的 ADS 变更占比。
- 关键控制的网络安全测试证据时效。
- 在传感器健康异常未解决情况下运行的车辆数。
- 从现场事件到跨车队模式检测的耗时。
- 要求双人审批的批量车队动作占比。
- 受网络影响场景在仿真、SIL、HIL 与场地测试中的覆盖率。
- 吊销操作员、车辆或服务凭据所需时长。
- 无法用保留证据重建的运行事件数。
指标应链接到底层车辆群与证据，而不是停留在孤立的看板百分比上。
ThreatZ 如何支持运行级保证
ADS 保证需要一个把架构、软件、模型、威胁、控制、测试、Release、运行事件、事件、供应商与车队配置连接起来的模型。ThreatZ 可提供网络安全可追溯层，把设计期分析与现场证据、变更决策连接起来。
一个可行的试点可聚焦单个远程辅助工作流或单条 ODD 执行链。映射权限与数据路径，把控制连接到验证与运行证据，并证明一个可疑事件能被追溯到受影响的软件、车辆与保证声明。
常见问题
AV 网络安全主要是防远程入侵吗？
不是。它还覆盖传感器、地图、模型、配置、车队服务、远程运营、软件变更与支撑安全行为之运行证据的完整性。
ODD 在网络安全中的角色是什么？
ODD 定义 ADS 可在哪些位置与条件下运行。安全控制必须保护用于判定这些条件是否满足的数据、配置与授权。
远程操作员是否可以绕过车辆安全边界？
最安全的设计让独立的车辆约束保持权威。远程辅助应被狭义定义、经过认证、有日志，且无法产生无约束的控制。
运营方如何界定 ADS 网络事件范围？
保持完整的部署与配置可追溯性。运营方应能识别每一辆使用受影响软件、模型、地图、硬件、策略或服务的车辆。
哪种测试环境最重要？
单一环境都不够。仿真提供规模，SIL 与 HIL 提供受控的技术证据，封闭场地测试验证物理行为，运行监测揭示真实世界的边缘案例。
权威参考
- NHTSA Standing General Order on Crash Reporting
- NHTSA Automated Vehicle Safety
- UNECE UN Regulation No. 157 - Automated Lane Keeping Systems
- UNECE overview of automated vehicle regulations