汽车网络安全不能只做一次渗透测试：TARA如何把风险贯穿研发与供应链？
谈思实验室
2026年11月5日 17:49
上海
去阅读
点击上方蓝字谈思实验室
获取更多汽车网络安全资讯
摘要
随着汽车电子电气架构、车载软件和云端服务不断融合，汽车网络安全已经不再是单个ECU或某个通信接口的安全问题。ISO/SAE 21434、UNECE R155和R156分别从工程、管理体系和软件升级等角度建立安全要求。本文从TARA方法出发，拆解车企如何识别威胁、评估风险，并将安全要求落实到主机厂与供应商的研发协作中。
一辆智能汽车包含数十甚至上百个电子控制单元（ECU），连接着车载通信网络、智能座舱、辅助驾驶系统、云端服务和OTA升级平台。
这些系统由不同供应商开发，通过复杂的软硬件接口集成在一起。这意味着，一个组件的安全问题，可能通过系统连接关系影响整车。
过去，企业可能更多依赖渗透测试、漏洞扫描和安全检测发现问题。但这些测试往往只能覆盖特定时间、特定系统和特定测试范围。
真正的汽车网络安全，需要从产品设计阶段开始识别风险，并持续管理到车辆停止运营。其中，TARA就是汽车网络安全工程中非常重要的一种风险分析方法。
01
先理解三个标准：ISO 21434、R155与R156
汽车网络安全领域有三个经常被提及的标准和法规。它们解决的问题不同，但共同构成了汽车网络安全管理的重要基础。
ISO/SAE 21434：汽车网络安全工程标准：
ISO/SAE 21434:2021是国际汽车网络安全工程标准，覆盖车辆电子电气系统从概念设计、产品开发、生产，到运行、维护和退役的整个生命周期。
它关注的是：企业应该如何将网络安全风险管理融入汽车产品研发和生命周期管理。
UNECE R155：网络安全与网络安全管理体系
R155是联合国欧洲经济委员会制定的车辆网络安全法规，涉及车辆型式批准及制造商网络安全管理体系（CSMS）。
它关注的不只是某个零部件有没有漏洞，还包括制造商是否具备识别、评估、监测和应对网络安全风险的组织能力。
UNECE R156：软件升级与软件升级管理体系
R156重点关注软件升级及软件升级管理体系（SUMS）。随着汽车越来越依赖OTA升级，企业需要建立软件版本识别、升级过程管理和升级安全保障机制。
简单理解：
- ISO 21434：告诉企业如何开展汽车网络安全工程。
- R155：关注企业是否建立了有效的网络安全管理体系。
- R156：关注软件升级是否具备可管理、可追溯的安全机制。
三者不能相互替代。
02
什么是TARA？它如何识别汽车网络安全风险？
TARA，全称Threat Analysis and Risk Assessment，即威胁分析与风险评估。
它的核心目标是：
在系统开发早期识别可能遭受的网络攻击，分析攻击可能造成的影响，并根据风险制定对应的安全要求。可以将其理解为汽车研发阶段的一套系统性安全风险分析方法。一个典型的TARA过程，可以拆解为以下几个步骤。
第一步：确定分析对象（Item Definition）
首先明确要分析什么。
例如：
- 智能座舱系统；
- T-Box车载通信终端；
- 车载网关；
- ADAS辅助驾驶系统；
- OTA软件升级系统。
分析对象不同，系统边界和风险场景也会不同。
第二步：识别资产（Asset Identification）
Asset是需要保护的关键对象。
例如，车辆通信数据、用户身份信息、车辆控制指令、软件升级包、加密密钥等。
识别资产的同时，还要明确需要保护的安全属性：
- Confidentiality：机密性，防止信息被未授权获取。
- Integrity：完整性，防止数据被非法修改。
- Availability：可用性，确保系统能够正常运行。
第三步：识别损害场景与威胁场景
损害场景（Damage Scenario）关注攻击可能造成什么后果。
例如，未经授权的控制指令可能影响车辆功能，敏感数据泄露可能侵犯用户隐私。
威胁场景（Threat Scenario）则进一步分析，什么样的安全问题可能导致这些后果。
第四步：分析攻击路径与可行性
Attack Path指攻击者可能通过哪些系统接口或组件关系达到攻击目标。
企业需要结合系统架构，分析外部通信接口、软件组件、身份认证机制和系统间信任关系。
同时评估攻击所需的条件和实现难度。
第五步：风险评估与处置
将潜在影响和攻击可行性结合，判断风险等级。
随后决定风险处置方式，例如降低风险、接受风险、转移风险或避免相关风险。
第六步：形成网络安全目标与技术要求
根据风险评估结果，形成Cybersecurity Goals（网络安全目标），进一步转化为可执行的技术要求。
例如：
- 安全启动（Secure Boot）；
- 安全诊断访问；
- 密钥管理；
- 网络隔离；
- 通信认证与加密；
- 安全日志与异常检测。
至此，风险分析才真正与产品研发建立联系。
03
为什么软件定义汽车时代更需要主机厂与供应商协同TARA？
过去，汽车系统相对独立，供应商主要负责各自零部件的开发与安全测试。但在软件定义汽车（SDV）架构下，车辆功能越来越依赖多个控制器、软件平台和云端服务之间的协同。
单个供应商完成自己的安全分析，并不意味着整车就一定安全。例如，某供应商负责开发车载通信控制单元，另一家供应商负责座舱系统，主机厂负责整车电子电气架构集成。如果每家企业只分析自己负责的组件，就可能遗漏跨组件的风险。
2026年6月，一篇发表于《Computers, Materials & Continua》的研究论文提出了面向主机厂与供应商的TARA协同模型。
研究重点包括：
- 将供应商层面的风险分析结果整合到整车层面；
- 根据整车视角重新评估系统风险影响；
- 结合电子电气架构和技术攻击路径进行分析；
- 细化信号层面的资产识别；
- 提升不同供应商之间风险分析的一致性和可追溯性。
研究者还将这一方法应用于虚拟软件定义汽车模型中的后部驾驶控制单元，开展了案例验证。
需要说明的是，这是一项提出协同分析方法的研究，并不意味着该方法已经成为行业统一实施标准。
但它揭示了一个重要问题：
汽车网络安全不能只依赖各供应商分别完成安全分析，还需要建立整车层面的风险整合机制。
04
企业如何将TARA真正落地？
对于车企和Tier1供应商而言，可以从以下五个方面着手。
- 建立完整的资产清单
不仅识别软件和硬件，还要识别通信接口、数据、密钥及关键业务功能。
- 建立系统架构与数据流关系
明确不同ECU、车载网络、云平台之间的数据交互和信任边界。
- 建立可追溯的TARA记录
每项风险都应能够追溯到对应资产、威胁场景、影响分析和风险处置结果。
- 将安全要求分配到供应链
明确主机厂、Tier1及其他供应商各自承担的安全责任，避免系统集成阶段出现责任空缺。
- 将风险管理延伸到车辆运行阶段
持续关注漏洞情报、软件更新、异常事件和安全事件响应，必要时重新评估既有风险。
05
结语
汽车网络安全不是一次渗透测试，也不是在产品量产前完成的一份安全检测报告。它是一套贯穿产品设计、研发、生产、供应链协作和车辆运行的持续性工程管理过程。
对于智能汽车产业而言，真正需要建立的不是孤立的安全检测能力，而是从资产识别、风险分析到安全要求落地，再到持续监测和风险处置的完整闭环。从发现漏洞，走向管理风险，这才是汽车网络安全工程化建设的关键。
end
谈思汽车媒体门户
精品活动推荐
AutoSec系列沙龙
专业社群
部分入群专家来自：
新势力车企：
特斯拉、理想、极氪、小米、零跑汽车、阿维塔汽车、智己汽车、小鹏、岚图汽车、蔚来汽车、吉祥汽车、赛力斯......
外资传统主流车企代表:
大众中国、大众酷翼、奥迪汽车、宝马、福特、戴姆勒-奔驰、通用、保时捷、沃尔沃、现代汽车、日产汽车、捷豹路虎、斯堪尼亚......
内资传统主流车企：
吉利汽车、上汽乘用车、长城汽车、上汽大众、长安汽车、北京汽车、东风汽车、广汽、比亚迪、一汽集团、一汽解放、东风商用、上汽商用......
全球领先一级供应商：
博世、大陆集团、联合汽车电子、安波福、采埃孚、科世达、舍弗勒、霍尼韦尔、大疆、日立、哈曼、华为、百度、联想、联发科、普瑞均胜、德赛西威、蜂巢转向、均联智行、武汉光庭、星纪魅族、中车集团、潍柴集团、地平线、紫光同芯、字节跳动、......
二级供应商(500+以上)：
中科数测、ETAS、BlackDuck、NXP、上海软件中心、Deloitte、奇安信、为辰信安、云驰未来、信长城、泽鹿安全、纽创信安、复旦微电子、天融信、奇虎360、中汽中心、中国汽研、上海汽检、加特兰微电子、浙江大学......
人员占比
公司类型占比
文章
不要错过哦，这可能是汽车网络安全产业最大的专属社区！
首发!小米雷军两会上就汽车数据安全问题建言：关于构建完善汽车数据安全管理体系的建议
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论