For automotive there's a standard, ISO-26262:2018, for series produced vehicles that deals with functional safety. I'll try to illustrate how that attempts to deal with risk, or rather, ensuring safety (=> absence of risk in the case of e.g. a failure in electric/electronic element). Part 5 of this standard deals with software development.
In short, you define 'safety goals' (SG, a top level safety-related requirement) for a system of the vehicle, at the vehicle level. For this system you perform a hazard and risk analysis (HARA) and its report will contain/output the SGs.
Each specific SG (usually) have an associated 'automotive safety integrity level' (ASIL A, B, C or D) that depends on how bad it might be if the safety goal was violated. The ASIL level then results in different sets of requirements being placed on the development of the system, including requirements on the development of software. An ASIL D means the toughest quality standard, and ASIL A is the least tough ASIL quality standard. Then there is 'QM', which isn't ASIL, and means the ISO standard doesn't require anything in particular, sow we're left with the company's normal quality management.
Basically the intention is to ensure spending enough effort on the more important safety-related parts, including making sure they're sufficiently verified and validated.
For example, the SG might be something like 'The vehicle shall prevent inadvertently starting to move more than 0.3 metres when at standstill (ASIL C)'. The reason for the SG, found in the HARA report, might e.g. that buses often park close to each other while pedestrians walking between them. And if a bus would start to move on its own due to a fault, that could be bad for someone standing in front the bus - they or the driver might e.g. not notice it in time.
From this SG, the engineers derive functional safety requirements, and then technical safety requirements. It's an iterative process depending on the number of levels of systems, but eventually we'll reach a system with an ECU, for which we derive requirements on its software.
Through this process, the ASIL is passed on with the requirements. So you might have a software requirement that ultimately traces back to the SG above that says 'The software system shall command the brakes to be applied while the vehicle is at standstill and the accelerator pedal is unpressed (ASIL C)'.
Note: I'm simplifying quite a bit here, e.g. skipping safety mechanisms, ASIL decomposition and freedom of interference. There's also a lot about doing fault tree analysis, FMEAs, diagnostic test coverage. For software development it also results in requiring a lot of verification (e.g testing) at various levels.
I hope this helps