Correlens

Use case · Software-defined vehicles

When the vehicle is software, security is a release discipline.

A software-defined vehicle decouples the software from the hardware it ships on: functions consolidate from a hundred fixed ECUs onto zonal controllers and central computers, features arrive over the air, and the car is never finished. Industry estimates already put a premium vehicle at around a hundred million lines of code, with projections several times that. Every release changes the risk picture, and the security work has to move at the same cadence.

Book a demo
Use case · Software-defined vehicles

What changed

The car became a computer with a warranty.

Three shifts define the software-defined vehicle, and each one reshapes what securing it means.

The architecture consolidatedDistributed ECUs give way to zonal controllers and central high-performance computers behind hardware abstraction and service-oriented interfaces. Less wiring, more software, and risk concentrated on shared compute.
The product is never finishedFeatures, fixes and whole business models ship over the air across a vehicle life that can span two decades. The software inventory a regulator sees today is not the one on the road next quarter.
Two worlds share the siliconSafety-certified functions and fast-moving consumer-grade code now run side by side on the same computers, built by teams with different toolchains, cadences and definitions of done.

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.

Driver confirming an over-the-air software update on the infotainment screen
One confirmation on the screen; one release across the fleet.

The hard part

Integration hell is a security problem.

The challenges the SDV field names are exactly the ones that decide whether security keeps up. The connecting thread: every one of them changes your software inventory faster than an annual assessment can see.

Scale Hundreds of interdependent subsystems and stacks; industry projections reach several hundred million lines of code per vehicle by 2030.
Integration Software from dozens of organizations that never shared a toolchain has to land on one architecture, release after release.
OTA lifecycle Every update campaign is a fleet-wide software release: tested, secured and accounted for per variant, at automotive scale.
Legacy coexistence New central compute ships alongside CAN-era ECUs that cannot be updated over the air; both are your attack surface.
Continuous homologation Certify-once-at-start-of-production fails when the software keeps changing; R155, R156 and ISO/SAE 21434 evidence has to stay current with the fleet.
Security cadence A growing attack surface and a moving codebase mean vulnerability monitoring has to run at release speed, not audit speed.

Where Correlens fits

Security work that moves at release speed.

A release is a risk eventEvery OTA changes the software inventory. Each release is diffed against the last, and what changed is re-enriched automatically: new components, new versions, new exposure.
The integration, inventoriedAdaptive AUTOSAR, embedded Linux, Android Automotive and safety RTOS stacks live on the same vehicle. One inventory resolves every component to the node and program it actually runs on.
OTA with a recordUNECE R156 and ISO 24089 expect updates to be managed and accounted for. A release-to-release diff is exactly the component-level record an update review asks for.
Continuous, not annualMonitoring and triage run at the pace of your pipeline, matching the continual activities ISO/SAE 21434 clause 8 expects, so a yearly assessment stops being an archaeology project.

The release loop

From build to fleet, with the evidence attached.

The platform sits beside your release pipeline, not inside your codebase: each software bill of materials that leaves the build is gated, enriched and diffed, and the findings queue follows the release, not the calendar.

  • Integration hell, made legible. When a supplier drops a new stack into the release, the diff shows what actually changed and what it brings along.
  • Regressions surface immediately. A downgraded or re-introduced component is a diff line, not a surprise in the next audit.
  • The queue follows the release. Findings attach to the release that introduced them, with an owner and a state.
Release 24.31 vs 24.26sample data
+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
sample data · release-to-release diff, enriched on import

Bring one release cycle to the demo.

Book a demo