2026-11-09 01:05:43 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

大众重写汽车软件：CARIAD的转向，与云端数据留下的考题

谈思实验室

2026年11月7日 17:40
上海

去阅读

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

冬季试验场上的新起点

2026年3月，大众公布了一轮发生在美国凤凰城和瑞典阿尔耶普卢格的测试结果。大众、奥迪、Scout与合资公司RV Tech的工程师，把新电子电气架构装进参考车辆，验证四驱、牵引力控制、行驶性能以及OTA更新。照片里的ID.EVERY1使用临时车身，官方特意注明，它是技术原型，不代表最终量产车型。这是一项开发里程碑，距离消费者拿到产品仍有后续工程工作。

如果把这张照片放回大众的软件历史，它的意义比一次冬测更大。六年前，大众希望依靠集团内部的软件组织，把分散在不同品牌和供应商之间的能力集中起来；如今，下一代架构的研发现场，已经出现美国电动车公司Rivian的团队。变化不只是合作名单变长了，而是大众重新划分了哪些技术自己做、哪些技术共同开发、品牌又应该在哪一层保持差异。

与此同时，汽车软件的责任也伸出了车身。2024年末，安全研究人员披露，大众集团部分联网电动车的车辆及位置数据曾能从互联网获取。这场事件没有证明车辆的制动或转向遭到接管，却显示：即使车内控制系统工作正常，云端处理位置数据的方式，仍可能伤害车主。理解大众的转型，需要同时看到试验场上的架构演进与车辆背后的数据系统。

图 V2｜搭载SDV架构、使用临时车身的ID.EVERY1参考车在冬测中。官方说明：技术原型，不供销售，外观不代表最终量产车型。

把软件集中起来，为何比建立一家新公司更难

大众的统一化愿望有清楚的业务起点。奥迪2020年报告写道，集团计划把车载软件自主开发比例从当时约10%提高至2025年的60%以上，同时保留数据主权与数字业务创造的价值。这记录的是转型起点的目标，并不能代表后来全部兑现。2020年建立的Car.Software Organisation，在2021年3月改名为CARIAD。彼时的官方说明同时列出MEB车型更新、PPE高端电动车平台，以及面向全集团的E³ 2.0平台，任务已经跨越存量维护与未来研发。

传统的供应商分工让车企能采购成熟部件，也给软件整合留下难题。以一个由手机发起的远程空调请求为例，它需要经过账户、云服务、通信模块，再到负责车身与空调的控制器。每个部件单独通过测试，并不等于整条链路在不同版本下都能正确工作。品牌越多，硬件批次、接口与配置组合越多，平台团队越难仅靠增加程序员来消化验证工作。对集团软件团队而言，难点往往发生在部件之间。

大众内部的实践研究提供了更具体的视角。Jan Kantert与Michael Nolting在2021年论文中指出，连接真实汽车要面对开发周期长达数月的既有系统；他们介绍了内部核心团队、动态测试阶段及功能开关等办法，缩短从开发到交付的时间。这说明转型不仅要写出新代码，还要让新代码进入旧系统时能够分阶段验证。软件组织成立，只完成了组织边界的调整，研发接口与发布流程还需要重新建立。

从平台雄心，回到必须交付的汽车

当软件进度开始影响新车，组织问题便变成产品问题。保时捷2022年上市招股文件明确披露，CARIAD及集团在E³ 1.2平台上的开发延迟，已经导致纯电Macan的投产时间推后。相比笼统的“传统车企不懂软件”，这份风险披露更能说明矛盾：车辆的机械开发、工厂准备与软件成熟度必须在同一个节点汇合，任何一条关键路径落后，都可能让整车等下去。

2023年5月，大众宣布重组CARIAD，任命此前负责宾利制造业务的Peter Bosch自6月1日起担任首席执行官。时任集团首席执行官Oliver Blume给出的方向，包括重新梳理与品牌的接口、为软件架构制定现实的实施次序，以及扩大技术伙伴关系。任用有集团转型经验的管理者，至少传递出一个明确的组织意图：软件项目要更紧密地接上品牌与整车交付，而不能只在自己的平台路线图上前进。

随后出现的产品能够帮助读者理解，所谓平台并非只是一套车机界面。奥迪2024年发布的E³ 1.2说明显示，它与CARIAD共同开发，以五台高性能计算机分担动力及底盘、驾驶辅助、信息娱乐、舒适功能和中央联网等任务，并引入千兆以太网，支持无线更新。品牌再将软件组件应用到具体车型。集中计算改变了功能的承载方式，也让系统之间的接口、隔离与更新策略成为整车设计的一部分。

奥迪对五台计算机的分工还显示，车内与车外并没有被简单地揉成一个系统。负责中央联网的HCP5连接域计算机与外部数字服务，驾驶辅助、动力控制则有各自的计算职责。这样的设计让功能能够共享高性能通信，又给分区管理保留了基础。不过，域之间仍要交换状态，软件更新仍要维护版本依赖，安全能力最终取决于具体实现与验证，不能只靠计算机数量来判断。

从安全角度看，计算集中既能减少重复实现，也会扩大共用组件出错的影响范围。一个供多车型使用的身份认证或通信组件，修复后可以让大量车辆受益；它的缺陷也可能跨车型传播。因此，平台复用必须配套版本追踪、受影响车辆识别和兼容性验证。平台的研发投入里，也需要包括车辆售出后多年持续识别与修补缺陷的成本。

图 V1｜Peter Bosch。大众2023年任命公告配发的官方人物照，并非研发现场照片。

Rivian与中国团队，改变了统一平台的路径

2024年11月，大众与Rivian宣布启动合资公司，合作交易规模上限为58亿美元。协议围绕软件、控制器及网络架构展开，并以Rivian既有电子架构和软件技术为基础。2024年年报确认，合资公司于11月13日开始运营。这里需要分清：总交易上限涵盖对Rivian及合资公司的不同投资安排，不等于CARIAD当年支出，也不等于全部资金当时已经支付。

引入Rivian，意味着大众获得了一条不同于完全内部重建的技术路径。对一家多品牌车企来说，共同基础软件能帮助摊薄研发投入，但大众品牌、奥迪与Scout仍要把各自的功能与硬件接入共同架构。2026年冬测新闻还提到，品牌软件专家将前往RV Tech学习架构与代码，再返回部门承担知识传递。这些安排透露出合作的实际难点：拿到技术许可之后，集团内部仍然要具备理解、集成与维护它的能力。

中国市场则形成了另一种分工。大众2025年年报介绍，CARIAD中国、大众汽车中国科技公司与小鹏共同开发中国电子电气架构CEA，酷睿程则由CARIAD与地平线合作推进驾驶辅助。到2026年11月3日，大众中国称，CEA已经赋能三家合资企业的五款全新车型，并在年内进行了软件迭代。后者是企业发布的进展口径，不能据此推导所有车型、所有功能已经统一，更不能直接推导其安全效果。

硬件选择也在进入新的合作框架。2026年1月，大众与高通签署意向书，拟从2027年起，为与Rivian合资开发、面向西半球的区域式架构提供信息娱乐等芯片能力。意向书仍须与最终供货和量产结果区分，但它表明，软件转型已经延伸到计算平台采购。架构合作、芯片方案与品牌功能要在同一时间表上协同，才能避免软件准备好之后，再等待适配硬件。

这条路线与早期“全集团一个平台”的表达相比，显得更分层、更区域化。美国伙伴提供架构基础，中国团队应对本土产品节奏与功能需求，CARIAD继续承担软件能力。合作能缩短部分研发路径，却不会自动缩短责任链：代码缺陷由谁修、车辆更新由谁批准、云端数据由谁处理，都需要落到具体合同、接口与运营流程。把合作对象的技术变成集团可持续维护的产品，才是下一阶段真正的工作。

约80万辆车的数据，把问题引向云端

另一条时间线发生在2024年。12月27日，Michael Kreil与Flüpke在混沌计算机俱乐部38C3大会介绍研究，称约80万辆电动车的移动数据及车主联系信息曾缺乏充分保护。德国汽车俱乐部ADAC同日报道，涉及大众、奥迪、斯柯达与SEAT等品牌，数据位于亚马逊云存储环境，其中约46万辆车涉及更精细的位置数据。约80万辆是受影响车辆规模，不能写成80万名车主全部被识别，更不能写成80万辆车被远程控制。

研究者在38C3原始投影片中，展示了未关闭的诊断内存转储入口，以及从内存对象中查看AWS访问密钥的画面。演讲总结页还列出坐标未降低精度、一个泄露密码未被停用等当时的问题。诊断信息、运行凭据与数据精度因此组成了需要连续审查的链条；这些内部凭据也不能与企业所称未受影响的客户登录密码混为一谈。原始材料并不支持把事件简单归因为公开的存储桶。

ADAC转述大众回应称，问题已被修复，密码与支付数据未受影响；CCC于11月26日通知了CARIAD。企业还表示，访问过程复杂、多阶段，研究人员接触的是假名化车辆数据。德国广播电台随后报道，CARIAD表示当时没有第三方滥用数据的迹象。这些话应作为企业回应呈现。“没有发现滥用”描述的是调查所得，不能当成已经排除一切外部访问的证明。

位置数据为何仍值得重视？因为假名化通常只是把直接身份替换为编号。若一个编号长期在同一地点夜间停留，再与工作日的目的地对应，数据使用者就有机会推断家庭与工作关系。这个风险分析并不依赖声称每辆车都完成了身份关联。它提醒车企，即使数据表里没有姓名，时间与空间的组合仍可能具备识别价值；数据精度、保存时长与可关联性，必须一起评估。

数据集中还有一个与车内平台相似的规模效应。把不同车型的充电或诊断数据放进统一分析环境，可以帮助寻找共性问题，却也让单一权限错误影响更多记录。一份本来只为算法调试保存的明细，若长期保留、又能与其他业务表连接，便可能逐渐拥有远超最初目的的信息价值。对研发人员而言，判断数据是否必要，不能只看单个字段，还要看它与时间、车辆编号及其他系统组合后能说明什么。

同样需要克制的是技术归因。公开报道不足以让外界还原全部内部权限配置、日志与审计过程，本稿不把事件简化成某个云厂商的通用漏洞，也不认定区域控制器或OTA机制导致了数据暴露。车内更新安全、云端访问控制和数据最小化属于相连但不同的工作层面。一次云端事件能说明后端治理出现了缺口，无法单独证明整个软件转型路线失败。

下一轮交付，要同时交出数据治理能力

把两条时间线放在一起，大众面对的工程任务更加具体。统一底层软件需要共用接口，而数据治理需要明确边界。车辆为充电优化采集哪些状态、是否需要精确位置、信息经过哪些后端服务、保存多久，以及售车或解绑后如何处理关联关系，都应该在功能上线前回答。否则，功能团队只看到采集价值，平台团队只看到存储能力，最终却没有一个角色对组合后的隐私风险负责。这些是对治理责任的分析，是否落实仍需具体证据。

研发环节也需要把“能运行”与“可运营”放在一起验证。一个新接口不仅要测试正常账户能否读取状态，还要测试换一辆车的标识能否越权、测试环境的配置能否进入生产，以及运维凭据泄露后的权限范围。用于分析的数据可以降低位置精度、缩短保留时间，并限制跨表关联；与业务无关的服务账户不应获得整库读取权。这些措施无法承诺零风险，却能在出错时减少暴露范围与追责盲区。

发生披露之后，修补错误配置也只是开始。车企还需要依据日志确认哪些记录可能被访问，检查同类服务是否存在相同问题，并让保留策略覆盖历史副本与备份。品牌面对车主，软件子公司掌握技术细节，云服务商提供基础设施，几方必须共同还原时间线。合作关系越多，预先约定取证、通知与整改的责任就越重要，否则组织之间的信息等待，可能继续拉长用户无法获得解释的时间。

2026年11月的大众已经能展示在中国推进的CEA车型，也能拿出RV Tech完成冬测的阶段证据。它的软件故事因此不能停留在“自研失败、转向外包”的简单判断，更不能因为几次技术演示就宣告转型完成。对车主来说，真正可感知的结果，是功能持续稳定、漏洞能够修复、数据用途能够解释，并在问题发生后得到清楚的处理信息。

图 V3｜大众中国用于介绍CEA电子电气架构的官方主题示意图，非真实漏洞现场或技术拓扑。

CARIAD的变化显示，大型车企的软件能力可以通过内部整合、品牌协作与外部伙伴共同形成。但车辆售出后的责任必须有人持续承担。大众下一阶段是否成功，既要看新架构能否进入量产，也要看数据系统能否经得起独立审视。试验场验证的是汽车在严寒中能不能正常工作；云端治理要回答的，则是车辆持续联网之后，用户的生活能否获得同样认真、持续的保护。

end