TL;DR: Software-defined vehicles now rely on tens of millions of lines of code, 40 to 70 software packages and mostly remote attacks, according to RunSafe Security, so automotive software security has become a safety issue as much as a cyber issue. Runtime protection, OTA patching and supply chain control matter because memory flaws and third-party components can cascade into vehicle-level harm.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on RunSafe Security's blog post: Automotive software security now determines whether SDVs can absorb complex code, remote attack paths and supplier risk without turning safety functions into liabilities.
Why it matters: This matters to security and identity practitioners because modern vehicles blend embedded software, connected services and OTA lifecycle control, so governance has to span build, deploy and update trust.
By the numbers:
- The SDV market is projected to grow from USD 390.29 billion in 2026 to USD 4162.14 billion by 2034.
Context
Software-defined vehicles are cars whose core functions depend on software, not just hardware. That shift expands the attack surface because braking, steering, ADAS, infotainment, telematics and over-the-air updates now sit inside one software supply chain, and the governance problem is no longer isolated device hardening but lifecycle control across all of those layers.
In connected automotive environments, software trust has to be managed across development, deployment and update paths. That makes the identity of software components, suppliers and update channels part of vehicle security governance, even when the underlying risk is operational rather than IAM-centric.
Key questions
Q: How do memory safety flaws turn into vehicle compromise in SDVs?
A: Memory safety flaws such as buffer overflows can let an attacker corrupt execution flow, run arbitrary code or escalate privileges inside embedded vehicle software. In SDVs, that matters because the compromised component may sit close to control logic, sensor processing or update paths, so a software bug can become a safety and operational issue, not just a local crash.
Q: Why does infotainment often become the first step in a vehicle attack chain?
A: Infotainment often becomes the first step because it is exposed to external inputs such as Bluetooth, USB, Wi-Fi, mobile apps and media files, then connected to vehicle networks. Attackers use it as an initial foothold to reach more sensitive ECUs, especially when network segmentation, secure gateways and least-privilege interfaces are weak.
Q: What is the best way to secure over-the-air vehicle updates?
A: The best way to secure over-the-air vehicle updates is with strong signing, validation of the update package, and a secure delivery path that enforces integrity, authenticity and anti-rollback checks. The update process should verify the signer, reject tampered images, and limit installation to authorised vehicle components through trusted boot and secure key management.
Q: How should suppliers prove software provenance for automotive systems?
A: Suppliers should prove software provenance with a software bill of materials, signed build artefacts, traceable source control, and controlled release records that link each component to its origin and version. That evidence helps buyers verify what code is present, which third-party libraries were used, and whether the delivered software matches the approved build.
Technical breakdown
Why memory safety flaws dominate embedded vehicle software
Vehicle ECUs and ADAS often rely on memory-unsafe languages such as C and C++, where buffer overflows, use-after-free conditions and other memory corruption flaws can create code execution opportunities. In embedded systems, those flaws matter more because the software is close to physical functions and often runs with limited runtime isolation. A compromise in one component can therefore affect control logic, sensor interpretation or safety behavior. The issue is not simply that bugs exist, but that the programming model itself makes exploitability more likely across a large installed base.
Practical implication: Prioritise runtime protections and memory-safe design choices where rewrites are not realistic.
How infotainment becomes the easiest entry path
Infotainment systems are attractive because they are connected, feature-rich and often exposed through multiple interfaces, including wireless connectivity and third-party integrations. When segmentation is weak, compromise of infotainment can become a bridge into more sensitive vehicle subsystems. That makes trust boundaries inside the vehicle as important as perimeter defenses outside it. The practical problem is not only initial compromise, but the movement from a convenience system into safety-relevant components through shared software paths or insufficient isolation. See the Automotive Ethernet and SOME/IP Security Guide.
Practical implication: Treat infotainment as a high-risk zone and enforce strict segment boundaries between user-facing and safety-critical software.
What OTA updates change in the lifecycle of automotive security
Over-the-air updates turn the vehicle into a continuously remediated system rather than a static product. That helps close vulnerability windows after deployment, but it also creates a permanent trust problem around update authenticity, delivery integrity and rollback safety. An OTA channel is only as secure as the signing, validation and operational controls around it. For SDVs, patching is therefore part of the security architecture, not a maintenance afterthought, because the vehicle remains exposed long after it leaves the factory. See the Connected and Autonomous Vehicle Security Guide.
Practical implication: Govern OTA signing, validation and rollback controls as core security mechanisms, not release logistics.
Threat narrative
Attacker objective: The attacker wants to manipulate vehicle behavior, reach safety-critical functions or gain code execution that affects multiple vehicles at once.
- Entry occurs through remotely reachable vehicle software, especially infotainment or other connected components that expose a wide attack surface.
- Credential_harvested is replaced here by memory exploitation, where a buffer overflow or similar flaw gives the attacker runtime control instead of a stolen secret.
- Escalation happens when that control is used to move from a less critical subsystem into ECUs, ADAS or other safety-relevant functions.
- Impact is vehicle manipulation, degraded safety behavior or fleet-scale exposure when shared software weaknesses exist across many models.
Breaches seen in the wild
- New York Times GitHub breach 2024: An exposed GitHub token gave an attacker The New York Times' repositories; the 270GB leak held 4,875 unique secrets.
- iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Automotive software security is now a lifecycle governance problem, not a feature-level hardening task. SDVs compress safety, connectivity and monetisation into one software stack, which means security failures can propagate across products, updates and suppliers. That changes the governance question from whether a component is hardened to whether the vehicle's software estate can be understood, controlled and updated across its entire lifecycle. Practitioners should treat build, release and post-sale operations as one security domain.
Memory safety is the named failure mode that keeps reappearing in embedded vehicle risk. The recurring issue is not abstract software complexity; it is exploitability in C and C++ code paths that sit close to control functions. When a buffer overflow can become runtime control, the gap is a memory-safety assumption, not simply weak configuration. Security teams should prioritise controls that reduce exploitability before deployment and limit the blast radius of any successful code execution.
Segmentation failures turn convenience systems into trust bridges. Infotainment, telematics and similar connected features are valuable precisely because they are well connected, but that connectivity becomes dangerous when lateral movement between components is possible. The governance lesson is that vehicle architecture must enforce separation between user-facing services and safety-critical controls. Practitioners should evaluate where shared software or weak isolation creates cross-domain movement paths.
Software supply chain risk is now inseparable from vehicle trust. SDVs depend on many packages, suppliers and open source components, so a defect or compromise in one layer can travel into deployed fleets. That makes software provenance, component inventory and supplier assurance foundational controls, not procurement extras. Teams should align supply chain governance with the same seriousness they bring to safety engineering.
OTA trust is the control that determines whether remediation actually reduces exposure. Update capability helps, but only if signing, validation and rollback protections are strong enough to prevent tampering and unsafe deployment. In practice, post-sale patching becomes part of the security control plane for the vehicle. Practitioners should verify that update channels can sustain security over long product lifecycles, not just ship fixes quickly.
What this signals
Vehicle software trust will increasingly be judged by isolation, not just functionality. As SDVs accumulate connected services and update channels, the security question shifts to whether a compromise can cross from convenience layers into safety layers. That creates a stronger need for architectural separation, provenance controls and update integrity across the full product lifecycle.
Runtime exploit resistance is becoming the practical alternative to full code rewrites. Many vehicle systems will continue to run memory-unsafe code for years, so the control problem is how to reduce exploitability now rather than wait for a perfect rebuild. Teams that can harden execution paths early will lower the chance that a single bug becomes a fleet issue.
For practitioners
- Define software trust boundaries across the vehicle stack Map which components can influence each other, then enforce isolation between infotainment, telematics, ECUs and ADAS so a compromise in one zone cannot automatically reach another.
- Introduce runtime protections for memory-unsafe components Apply build-time hardening and runtime memory protection to code paths that remain in C or C++ so exploitability is reduced without waiting for a full rewrite.
- Govern OTA updates as a security control Require signing, validation, safe rollback and telemetry for every update path so patching does not become a new attack surface.
- Demand SBOM-backed supplier assurance Require suppliers to provide SBOMs, map dependencies to the vehicle software bill and escalate components that lack clear provenance or timely vulnerability handling.
Key takeaways
- Software-defined vehicles expand the security problem from isolated components to a lifecycle-wide governance issue spanning code, suppliers and updates.
- The most visible technical risk is memory safety failure, which can convert a bug in embedded software into runtime control of vehicle functions.
- Security programmes should focus on segmentation, runtime hardening, OTA trust and software provenance if they want to reduce both fleet exposure and safety impact.
Related NHI Mgmt Group resources: Software Supply Chain Security Buyer's Guide · Connected and Autonomous Vehicle Security Guide · Automotive Ethernet and SOME/IP Security Guide · Vehicle Security Operations Centre Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while SLSA, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0004; TA0008 — Credential Access; Privilege Escalation; Lateral Movement | Vehicle compromise here relies on exploit paths that yield runtime control and movement across subsystems. |
| Recommendation — Map embedded exploit paths to ATT&CK tactics and hunt for ways a foothold can cross from one vehicle subsystem to another. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Connected vehicle surfaces fail when exposed interfaces and weak segmentation let attackers pivot. |
| Recommendation — Treat exposed vehicle interfaces as security misconfiguration risks and remove unnecessary trust between connected components. | ||
| SLSA | L3 — Build Provenance | Software provenance matters because SDVs depend on many suppliers and embedded components. |
| Recommendation — Require provenance evidence for vehicle software builds and artifacts before accepting them into production. | ||
| NIST CSF 2.0 | PR.PS-01 — Configuration Management | Vehicle software security depends on secure configuration, segmentation and controlled deployment across components. |
| Recommendation — Use configuration management to control vehicle software interfaces, trust boundaries and update paths. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The article centers on finding and reducing exploitable flaws before deployment and during product life. |
| Recommendation — Continuously discover and prioritise vehicle software vulnerabilities before they become fleet-wide exposure. | ||
Key terms
- Software-defined vehicle: A software-defined vehicle is a vehicle whose features, controls, and updates are increasingly managed through software and connected digital systems. It depends on centralized compute, remote updates, and supplier-integrated tooling, which makes access control and containment more important than in traditional vehicle architectures.
- Electronic Control Unit: An electronic control unit is a ruggedized computing module inside a vehicle that manages specific functions such as braking, steering, comfort systems, or driver assistance. Modern vehicles use many ECUs connected through internal networks, which means each unit becomes part of the security and trust boundary.
- Advanced Driver-Assistance Systems: Advanced Driver-Assistance Systems are vehicle technologies that support the driver with functions such as braking, steering, lane keeping, or collision warnings. They reduce manual workload but still depend on software, sensors, and control logic that can fail or behave unpredictably, making post-incident data capture essential.
- Over-the-Air Update: An over-the-air update is a wireless delivery of software, firmware, or provisioning data to a connected device. In security terms, it is also a trust decision, because the device must verify the sender, the payload integrity, and the intended recipient before accepting change.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners build the governance habits that underpin secure access across connected systems and software lifecycles.
Published by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org