A modern car ships more code than a commercial airliner — somewhere between 100 and 150 million lines across 100-plus electronic control units, sourced from Tier 1 suppliers, Tier 2 chipmakers, open-source libraries, and cloud backends that the automaker itself never wrote. That sprawl is exactly why connected vehicle software supply chain security has become a board-level concern rather than an engineering footnote. When Chrysler recalled 1.4 million Jeep Cherokees in 2015 after researchers Charlie Miller and Chris Valasek remotely killed a vehicle's transmission over cellular, the industry learned that a single unpatched telematics component could compromise a car's brakes, steering, and engine. A decade later, over-the-air updates, ADAS sensor fusion, and cloud-connected infotainment have multiplied the attack surface, not shrunk it. This piece walks through why the risk is accelerating, what regulators now require, and how automakers and suppliers can actually see what's running in their fleets.
Why does connected vehicle software supply chain security matter now?
Connected vehicle software supply chain security matters now because the average car has become a rolling network of untrusted, third-party code with a direct line to safety-critical systems. A single vehicle program can pull software from hundreds of Tier 1 and Tier 2 suppliers, each of whom bundles open-source components, proprietary drivers, and firmware blobs that the OEM never independently audits. Upstream Security's annual automotive cybersecurity reports have tracked a steady rise in incidents tied to APIs, backend servers, and telematics units rather than physical tampering — meaning attackers increasingly go after the software supply chain, not the car in the driveway. Add over-the-air (OTA) update pipelines, which let a compromised build server push malicious code to millions of vehicles simultaneously, and the blast radius of a single supply chain failure now looks less like a stolen car and more like a mass-casualty software incident. Toyota's 2022–2023 cloud misconfigurations, which exposed data tied to roughly 2.15 million vehicles over several years before discovery, are a reminder that the exposure isn't hypothetical — it's already happened at scale.
What actually runs inside a modern vehicle's software stack?
What runs inside a modern vehicle is a layered stack of ECUs, hypervisors, and third-party middleware that few automakers can fully enumerate today. A typical connected vehicle contains anywhere from 70 to over 150 electronic control units handling everything from infotainment and climate control to braking and steering, each running its own firmware, real-time operating system, and communication stack (CAN, LIN, Ethernet, or increasingly SOME/IP). Layered on top are ADAS modules doing sensor fusion from cameras, radar, and lidar; telematics control units maintaining a persistent cellular connection; and cloud services handling fleet telemetry, remote diagnostics, and OTA delivery. Every one of those components is itself built from a supply chain — a Tier 1 supplier's braking ECU might embed an RTOS licensed from a third party, a TCP/IP stack from another vendor, and open-source cryptographic libraries nobody on the OEM side has ever inventoried. Automotive cybersecurity supply chain risk lives precisely in that gap: the OEM owns the liability, but rarely owns visibility into every dependency baked into a supplier's binary.
How many known vulnerabilities are hiding in automotive components?
How many known vulnerabilities are hiding in automotive components is impossible to answer precisely, and that uncertainty is itself the problem. Automotive-grade Linux distributions, TCP/IP stacks like the one implicated in the 2020 Ripple20 disclosure (19 vulnerabilities in a single embedded stack used across medical, industrial, and automotive devices), and infotainment platforms built on Android or QNX all inherit CVEs from upstream projects on a rolling basis. A 2021 Assured Autonomy/industry analysis estimated that a single connected vehicle could contain code tied to hundreds of publicly disclosed CVEs across its combined ECUs and third-party libraries — most of them never tracked back to a specific vehicle model because no software bill of materials existed to make the connection. Without that mapping, a critical CVE disclosed against a widely used TLS library or RTOS component can sit unpatched in production vehicles for years simply because no one on the OEM side knows it's there.
What is an autonomous vehicle SBOM and why do regulators want one?
An autonomous vehicle SBOM is a structured, machine-readable inventory of every software component — down to open-source libraries and their versions — that ships inside a vehicle's ECUs, ADAS stack, and connected services. Regulators want one because you cannot patch, recall, or even assess exposure to a vulnerability like Log4Shell or Ripple20 if you don't know which vehicles contain the affected component. UNECE WP.29 Regulation No. 155, which became mandatory for new vehicle types in the EU, Japan, and South Korea starting July 2022 and extends to all new vehicles produced from July 2024, requires OEMs to demonstrate a Cybersecurity Management System covering the full supply chain, including third-party software. ISO/SAE 21434, published in 2021, complements it by defining how cybersecurity risk should be engineered and documented across the vehicle lifecycle, including supplier components. In the U.S., NHTSA's cybersecurity best practices and growing federal interest in SBOM mandates (following Executive Order 14028) are pushing the same direction. An autonomous vehicle SBOM turns "we think our braking ECU is probably fine" into an auditable, queryable record that can answer a regulator's or a customer's question in minutes instead of weeks.
How does ADAS software security differ from traditional automotive IT security?
ADAS software security differs from traditional automotive IT security because the failure mode isn't data theft — it's physical harm at highway speed. A compromised infotainment system might leak contact lists or location history; a compromised ADAS stack that fuses camera, radar, and lidar input to make steering or braking decisions can be tricked into misreading a stop sign, ignoring a pedestrian, or disengaging emergency braking, as researchers have repeatedly demonstrated against production ADAS systems using adversarial stickers, projected images, and sensor spoofing. That safety dimension means ADAS components fall under ISO 26262 functional safety requirements in addition to ISO/SAE 21434 cybersecurity requirements, and a supply chain gap in one directly undermines the other — a vulnerable third-party perception library isn't just a security bug, it's a safety defect. Because ADAS and increasingly autonomous driving stacks update frequently via OTA to improve model accuracy, the software supply chain security question becomes continuous: every model update, every sensor driver patch, and every dependency bump needs the same scrutiny as the original release, not a one-time certification.
How Safeguard Helps
Safeguard was built for exactly this gap between what automotive OEMs and Tier 1 suppliers ship and what they can actually see inside their own software. Rather than treating software supply chain security as a one-time compliance checkbox for WP.29 or ISO/SAE 21434 audits, Safeguard continuously generates and maintains accurate SBOMs across firmware, ADAS stacks, infotainment platforms, and cloud backends — mapping every open-source and third-party component down to the version actually running in a given ECU or vehicle model. When a new CVE drops against a widely used RTOS, TLS library, or sensor-fusion component, Safeguard correlates it against your real fleet inventory instead of a static spreadsheet, so you know within minutes which vehicle programs, supplier packages, and OTA update batches are actually exposed — not just theoretically at risk. For Tier 1 and Tier 2 suppliers, Safeguard provides a consistent way to generate and share machine-readable SBOMs with OEM customers, closing the visibility gap that lets vulnerable dependencies hide inside binaries nobody upstream ever inspected. And because build pipelines and OTA release processes are themselves part of the attack surface, Safeguard extends supply chain integrity checks into CI/CD — verifying provenance and signing at each stage so a compromised build server can't quietly push unauthorized code into a production release. The result is what regulators, insurers, and increasingly customers are starting to expect: a connected vehicle software supply chain security program that can answer "are we affected?" in minutes, not months, and prove it with evidence rather than assurances.