Here's more than you'd want to know about this:
Parts
The automotive parts like these sell in the millions so it makes sense to have dedicated product lines. Another requirement is that car manufacturers need to have certain certifications (someone mentioned MISRA but there are also SPICE/ISO, CMMI and others) and all those certification requirements trickle down to the last component. So if you really want to use jellybean parts you will be responsible for the mishaps, because the certification implies complete traceability.
Certain automotive parts are the exact technical equivalent of their hobby-grade stuff but they went through some cert tests and are proven automotive-capable. You sometimes pay 5x the price without getting anything extra. Obviously you cannot use other parts (even better and much cheaper) since the manufacturers did not go through the trouble of getting things certified. That's a sure way of getting easy money. Case in point: harddrives made for entertainment units.
Software
The airbag logic is very complex and it's usually done by a specialized company or outsourced from some universities. That's because big auto parts companies employ generally mediocre people. That's because they need a lot of them and cannot afford the best ones nor are they able to find so many. It's just how corporations work.
The designers/developers responsible with the product mostly change parameters and write them to the EEPROM.
There are well over 20 inputs for each of these units (accelerometers, crash sensors, speed, engine, doors, seatbelt, occupancy/weight, roll-over, ...) and AFAIK the default fail-safe behavior is to NOT trigger the airbag.
The airbag units involved in a crash that resulted in deployment generally cannot be reused. They blow some fuses up or make some other irreversible changes to the unit. I'm sure enterprising individuals can restore them but hopefully that is not happening. Usually the units get exchanged for a new one or from a another car. With newer cars the units need to be coded as well so that the CAN gateway can recognize them.
On a lot of [european] cars the battery also has a pyro charge that interrupts the positive lead in case of a crash. I am not sure if the detonation happens before airbag deployment or after, but I would guess the later.
Regarding the code, AFAIK there is absolutely no ASM allowed, no pointers, no C++ crazy features, no "funny" obfuscation, no multithreading and a few other "hacker" things which I forgot about. Exceptions have to be heavily reviewed and innovations (algorithm, optimisations) are most often discouraged.
Design
On the electronics side, most of the automotive supply stuff is heavily over-engineered. All kinds of watchdogs are put into place and all possible recordable errors are written to the EEPROM and counted. The generic OBD stuff cannot find all of them but a car-specific tool can.
Misc
IANAL but I haven't heard of any case where the data stored in the EEPROM was being used to monitor someone or make a spectacular legal case.
I find it more interesting that for motorcycles the stuff is less regulated and generally less safe and reliable, with the exception of [big] BMW motorcycles which share a lot of technology with their car counterparts from 5-10 years before.
Interesting
A bit off-topic but on my 2001 BMW I can access at least 100 individual CAN-speaking chips giving me access to thousands of parameters. They tell me how many times the electric windows have had an overload (trying to lower while frozen), wiper failures, ~20 PID parameters for the cruise control (I don't even have the buttons for that), 10 parameters for the auxiliary heating unit (no control over that either), >15 parameters for the interior heating, at least 4 points of calibration data for each parking sensor (8 of them). And that's just the small stuff.
Interestingly enough, the 2007 BMW K1200 motorcycle entertainment unit has the same innards as my original one. Including the cassette drive! And it speaks the same CAN protocol that has been made obsolete since 2004.