Most control units have moved to RSA signatures for updates. Some very modern units use ECDSA. AES encrypted update payloads (usually keyed per model line / unit type, not entangled with per-unit identity like other systems).

Modern safety processors have TEE and HSM just like any other modern embedded processors so you see those used (often incorrectly) to store key material and run TAs to lock secured system state (ie - a TA which answers “is the system in sample or series production mode”).

Flash is usually plaintext (see safety concerns) but embedded in the SoC package so you need some kind of exploit to get to it.

VM protection and obfuscation are unlikely on safety critical systems because the risk greatly outweighs the reward. On head units outside the safety boundary I’m  sure they’ll show up soon.

Lots of security theater is going on in Europe, see UN155 and UN156. Mostly this just expands the previous signature and encryption protections to more control units, but also adds a lot of theatrical nonsense like “IDS” in the vehicle.

I did a lot of research on previous generation VW stuff at https://github.com/bri3d

Rust is moving into the automotive space quickly. All of the middleware vendors like Tasking, HighTec, etc. are pushing safety-certified Rust toolchains now.

With that being said, only a few of the more recent ECU exploits are memory safety related. Memory safety definitely helps, but you can still write giant logic bugs in Rust. Most safety-boundary automotive stuff was already being done in faux-MISRA C. While MISRA certainly isn't bulletproof and the way automotive OEMs use it is _definitely_ not bulletproof, a lot of memory safety issues were already cleaned up.

Certainly both the code and the hardware gets more secure every year. Exploits on new control modules are dramatically more difficult to find and utilize than they were on older stuff.