A modern software-defined vehicle (SDV) runs on more than 100 million lines of code across dozens of ECUs, and most of the safety-critical portion of that code is still written in C or C++ — languages with no built-in memory safety. MISRA C, the coding standard maintained by the MISRA consortium since its first release in 1998, published its latest revision, MISRA C:2025, in March 2025. That update added new rules on top of the prior edition's baseline, bringing the standard to roughly 225 combined rules and directives spanning C90 through C18, and for the first time it explicitly states that AI-generated code must comply with the same rules as handwritten code, a direct response to LLM-assisted development creeping into embedded codebases. Meanwhile, an empirical study published in late 2025 catalogued 1,663 automotive-software CVEs disclosed between 2018 and 2024, analyzing their CVSS scores, attack vectors, and CWE categories across the industry. The pattern connecting these two data points is straightforward: SDVs have dramatically expanded the attack surface of vehicle software at the exact moment automakers are shipping more C/C++ than ever, over networks that used to be physically isolated. This post covers why memory safety and coding-standard compliance are now inseparable concerns for anyone shipping ECU firmware.
What makes memory safety different from a typical coding-standard violation?
Memory safety bugs fall into two categories that are both notoriously resistant to manual review: spatial violations (buffer overflows, out-of-bounds reads and writes) and temporal violations (use-after-free, double-free). A spatial violation happens when code accesses memory outside the bounds of an allocated object — a classic stack buffer overflow from an unchecked memcpy() call. A temporal violation happens when code accesses memory through a pointer after that memory has been freed or reallocated for something else, which is often exploitable but only manifests under specific timing or allocation patterns that unit tests rarely reproduce. Unlike a style violation — an unbraced if statement, an implicit type conversion — a memory-safety bug frequently doesn't crash immediately or at all in testing; it corrupts state silently and surfaces later, in a different function, under different load. That gap between cause and symptom is exactly why memory safety demands static analysis tooling rather than relying on QA to eventually trigger the fault path.
How much of real-world vulnerability data actually traces back to memory safety?
Independently, Microsoft and the Google Chrome security team have each reported that roughly 70% of the security vulnerabilities they fix in their own large C/C++ codebases are memory-safety issues — buffer overflows, use-after-free, and related classes. That consistency across two unrelated engineering organizations, maintaining different codebases for different purposes, is what elevated this from an internal engineering observation to a policy question. In June 2025, the U.S. Cybersecurity and Infrastructure Security Agency (CISA), alongside the NSA and FBI and Five Eyes partners, published "The Case for Memory Safe Roadmaps," joint guidance urging software manufacturers to either adopt memory-safe languages or apply rigorous, documented mitigations where legacy C/C++ codebases can't be rewritten. For automotive suppliers, where a full rewrite of a certified ECU codebase in Rust is rarely feasible on any near-term timeline, that guidance points squarely at static analysis, hardened compiler flags, and coding-standard enforcement as the practical mitigation path.
Why does MISRA C exist, and what changed in the 2025 revision?
MISRA C originated with the Motor Industry Software Reliability Association specifically because automotive C code runs safety-critical functions — braking, steering, airbag deployment — where undefined behavior isn't an acceptable risk. Guidelines like avoiding undefined and unspecified behavior, restricting pointer arithmetic, and banning implicit type conversions exist because C's specification leaves exactly the behaviors that cause memory-safety bugs open to compiler-specific interpretation. MISRA C:2025, published in March 2025, extended coverage through C18 and brought the standard to roughly 225 combined rules and directives. Its most notable addition responds to a problem MISRA didn't anticipate a decade ago: generative AI tools now write portions of embedded C, and the standard explicitly states that AI-generated code carries the same compliance obligation as code written by a human engineer. That's a meaningful statement of intent — it forecloses any argument that AI-assisted code is exempt from the review bar a certified ECU supply chain requires.
What role does AUTOSAR play alongside MISRA compliance?
AUTOSAR (AUTomotive Open System ARchitecture) is the industry-standard software architecture framework that defines how ECU software components are structured, communicate, and get integrated — it's a complement to MISRA's coding rules, not a substitute. AUTOSAR ships two platforms built for different ECU classes: the Classic Platform, built on an OSEK-based real-time operating system for traditional single-function embedded ECUs like body control modules, and the Adaptive Platform, built on POSIX, designed for the high-performance compute domains that SDVs increasingly centralize — ADAS, infotainment, and over-the-air update managers. That split matters for security posture because Adaptive Platform ECUs run more like general-purpose Linux systems, with dynamic memory allocation and a much larger third-party library surface, than the fixed-function Classic Platform ECUs MISRA C was originally written around. A memory-safety defect in an Adaptive Platform network stack is reachable in ways a Classic Platform sensor driver never is, which is why compliance programs increasingly treat the two platforms with different scrutiny levels rather than one blanket MISRA checklist.
How do ISO 26262 and ISO/SAE 21434 fit alongside coding standards?
ISO 26262, the automotive functional-safety standard, and ISO/SAE 21434, the automotive cybersecurity engineering standard, are the two companion frameworks automakers pair with MISRA and AUTOSAR compliance to build a complete SDV assurance case. Functional safety asks whether the system fails safely when something goes wrong; cybersecurity engineering asks whether an attacker can deliberately induce that failure. A memory-safety bug sits at the intersection of both: a heap overflow in a telematics control unit is simultaneously a functional-safety hazard (it can crash a safety-relevant process) and a cybersecurity vulnerability (it may be remotely triggerable over a cellular or V2X interface). Coding-standard compliance — demonstrable, auditable MISRA conformance backed by static analysis reports — is typically the artifact that satisfies both standards' requirement for documented risk mitigation, which is part of why regulators and OEM supplier contracts increasingly treat MISRA compliance reports as a required deliverable rather than a best practice.
Why does connectivity make this more urgent for SDVs specifically than for legacy vehicles?
Legacy ECUs mostly ran isolated, fixed-function code with no path for a remote attacker to reach a memory-safety bug in the first place — the vulnerability existed, but it wasn't reachable. SDVs remove that isolation by design: over-the-air update channels, cellular connectivity, V2X messaging, and centralized compute domains all create network paths into code that previously only executed in response to physical sensor input. The 1,663-CVE dataset spanning 2018–2024 reflects this shift toward a broader, more networked automotive attack surface as connected features have expanded across the industry. A spatial or temporal memory-safety bug that was theoretical in an air-gapped 2015 ECU is a remotely triggerable one in a 2026 SDV control unit that accepts firmware updates over cellular. That's the throughline connecting MISRA's 2025 revision, the CISA memory-safety guidance, and the growing CVE count: the code hasn't necessarily gotten worse, but the reachability of its defects has changed completely, and coding-standard compliance combined with rigorous static analysis is the primary lever teams have to close that gap before certification, not after an incident.