用例 · 软件定义的车辆
当车辆是软件时，安全就是版本控制的纪律。
软件定义汽车将软件与承载它的硬件解耦：功能从约一百个固定的 ECUs 整合到区域控制器和中央计算平台，功能通过远程更新持续交付，车辆也因此不断演进。行业估计，一辆高端汽车已包含约一亿行代码，未来可能达到这一规模的数倍。每次发布都会改变风险态势，安全工作也必须以同样的节奏推进。
发生了什么变化
汽车变成了一台带有保修的计算机。
三项转变定义了软件定义汽车，而每一项都重塑了保护它的方式。
架构整合分布式ECUs让位于硬件抽象和服务导向接口后的区域控制器和中央高性能计算机。减少布线，增加软件，风险集中在共享计算上。
产品永远不会完成功能、修复，甚至完整的商业模式，都会在长达二十年的车辆生命周期中通过远程更新交付。监管机构今天看到的软件清单，并不等同于下个季度实际在道路上运行的版本。
两个世界共享同一套芯片安全认证的功能和快速移动的消费级代码现在在同一台计算机上并行运行，由具有不同工具链、节奏和完成定义的团队构建。
Never finished, in practice
The update ships to the driveway, not the workshop.
An over-the-air release lands as one tap for the driver and a fleet-wide software change for you: new components, new versions, new exposure, all under type-approval obligations. The moment it is confirmed on that screen, your inventory has changed.
难点部分
集成地狱是一个安全问题。
软件定义汽车（SDV）领域所识别的挑战，正是决定安全能力能否跟上变化的关键。它们的共同点是：每项挑战改变软件清单的速度，都快于年度评估能够发现的速度。
规模
数百个相互依赖的子系统和软件栈；行业预测，到 2030 年每辆车的代码量将达到数亿行。
集成
来自数十个从未共享同一工具链的组织的软件，必须在一次又一次发布中汇聚到同一套架构上。
OTA 生命周期
每次更新活动都是一次大规模的汽车软件发布：经过测试、安全和按变体统计。
与旧系统的共存
新的中央计算与 CAN 时代的 ECUs 一起提供，无法通过无线方式更新；两者都是你的攻击面。
持续认证
生产初期的一次性认证在软件不断变化时会失效；R155、R156 和 ISO/SAE 21434 的证据必须与车队保持同步。
安全节奏
不断增长的攻击面和不断变化的代码库意味着漏洞监控必须以发布速度而不是审核速度运行。
Correlens 适合的位置
以发布速度进行的安全工作。
发布是风险事件每一次OTA都会改变软件清单。每一次发布都会与上一次进行比较，变化的部分会被自动重新评估：新的组件，新的版本，新的风险。
集成，已盘点Adaptive AUTOSAR、嵌入式 Linux、Android Automotive 和安全 RTOS 软件栈运行在同一辆车上。统一资产清单可将每个组件准确关联到其实际运行的节点和程序。
带有记录的 OTAUNECE R156 和 ISO 24089 期望对更新进行管理和说明。版本之间的差异正是更新审查所要求的组件级记录。
持续的，不是每年的监控和研判以您的流水线节奏持续运行，并与 ISO/SAE 21434 第 8 条要求的持续活动保持一致，使年度评估不再变成一场追溯历史的考古工作。
发布循环
从原型到车队，附带证据。
该平台位于您的发布流水线旁边，而不是嵌入代码库中：每次构建离开流水线时，软件物料清单都会被筛选、增强和差异分析，而发现结果则跟随发布，而不是日历。
- 集成地狱，变得清晰。 当供应商在发布中引入新的堆栈时，差异显示实际发生了什么变化以及带来了什么。
- 回归问题会立即显现。 降级或重新引入的组件是一个差异项，而不是下次审核中的意外。
- 队列跟随发布。 发现的问题与引入它们的版本关联，并指定所有者和状态。
+38
added
-11
removed
57
changed
9
new findings
2
regressions
OTAota-agent 1.7 → 1.8 · Telematics4 NEW CVES
OTAnav-render 2.9 → 3.0 · IVI Head UnitCLEAN
OTAtls-lib 5.6.3 → 5.4.0 · GatewayDOWNGRADE
示例数据 · release-to-release diff, enriched on import