What do you mean by this? The car itself is a single unit so you can assume the electronics inside communicate at some level (CAN networks usually), but the electronics are separated. You have a control unit for the engine, another one for the ABS, another for the gearbox and many others for various body control functions. Some of them communicate with each other over the CAN, but only transmit/receive messages of particular interest. For example, the ABS unit in some cases tells the engine control unit the vehicle speed. The engine control unit transmits the engine RPM to the body control unit for obvious reasons. The same for the anti-theft mechanism.
To the subject: Having outdated drivers in production level software is common practice. During final validation of the SW, before start of production, if some drivers are found outdated (even declared invalid by the driver/package owner), people do not jump to upgrade immediately. It undergoes a process of analysis: is there any critical bug which the new version fixes? Does it impact the current project configuration? If not, why upgrade? You run the risk of introducing a regression => requires extra validations which can take weeks or months. Nobody will approve that just to fix some bug without functional impact in that particular system. So when you claim that a certain package has to be updated to the latest version, you have to come up with arguments. "Newest is always better" does not count. There are countless examples when newer versions of some piece of SW fixed some bug but broke something that was working. SW updates after the majority of the validation process is finished happens only on a NEED TO HAVE basis.
All of this is just crying wolf so far.
But sure - best practices should be followed.