BENCHMARK REPORT · 2026

The Hidden Attack Surface of Automotive Software

We scanned 43 open-source components from the software-defined vehicle ecosystem across two axes of risk: known vulnerabilities and supply-chain trust. 55% of dependencies carried a CVE — and 826 packages carried a trust risk with no CVE at all.

A reproducible, dependency-level benchmark for security, product-security and compliance teams working under UN R155, ISO/SAE 21434 and the EU Cyber Resilience Act.

Your vehicle's real attack surface isn't the code you wrote.

Modern vehicles are assembled, not authored. 80 to 90% of a typical codebase is open-source and third-party code, pulled in through dependency trees most teams never fully map. That inherited code carries the exposure, not the software an OEM or supplier writes.

We measured it directly. Not a survey, not opinion: SCA and supply-chain trust scoring across 43 real automotive open-source components from Eclipse SDV / KUKSA, COVESA and Velocitas. Every finding is reproducible from public sources.

Two risk axes

known CVEs and package trust — neither alone is enough

Automotive-specific

SDV stack: Eclipse KUKSA, COVESA, Velocitas

Compliance-mapped

findings tied to R155, ISO 21434 and CRA obligations

What we found

automotive open-source components scanned

dependencies resolved across the corpus

distinct critical CVEs after de-duplication

packages flagged with a supply-chain trust risk

of components carried at least one critical vulnerability

packages with a version known to have shipped malware

55%

of resolved dependencies carried a known vulnerability. Vulnerable dependencies are the majority in this ecosystem, not the exception.

826

distinct packages carried a trust risk with no CVE: abandoned, starjacking, typosquatting, single-maintainer, or known malware. A clean scan is not safety.

23.7

unique critical CVEs per npm component on average — versus 2.3 in Rust. Density follows the ecosystem; every ecosystem was exposed.

No component can be assumed safe — on either axis.

Critical risk is structural, not random.

Average critical vulnerabilities / component

npm

23.7

Python

10.1

Java

6.5

C/C++

Rust

2.3

Critical-vulnerability density follows the package ecosystem. npm averaged 23.7 unique critical CVEs per component; Python 10.1; Rust 2.3. Lean dependency ecosystems are lower-risk — not free of risk. Even Rust carried a critical in 71% of its components.

The full report ranks all 43 components by name, scores supply-chain trust risks, and traces one transitive memory-safety flaw into a vehicle data path.

Inside the full report

Named component rankingAll 43 components ranked by unique critical CVEs, with severity breakdown and trust-flagged package counts.
Two axes of riskKnown CVEs plus supply-chain trust: abandoned, starjacking, typosquatting, single-maintainer and known malware.
The recurring packagesUtility packages like brace-expansion and bytes that spread critical risk across unrelated components.
A dependency cascadeOne transitive memory-safety flaw (bytes CVE-2026-25541) traced into a realistic vehicle data path.
Regulatory mappingFindings tied to R155, ISO/SAE 21434 and CRA deadlines — including the 24-hour reporting trap before SBOM.
Full appendixPer-component data for all 43 components, reproducible from public sources.

Get the full benchmark report

Stop guessing whether a new CVE — or an abandoned package with no CVE — actually affects your code. This report shows which automotive open-source components are exposed on both axes, maps findings to compliance requirements, and traces a real dependency cascade. And it's free.