Reddit mentions: The best risk management books

I haven't read Wasserman, but I briefly looked at the Amazon preview of it. Usually this is a good starting place for intermediate-level mathematical stats, but if the notation seems very daunting, I would recommend an actuarial text on probability to get you started (these usually avoid the plethora of notation) before you pursue mathematical stats. The two I recommend are Probability for Risk Management and Probability and Statistics with Applications: A Problem-Solving Text (my personal favorite, plus this one also covers the stats). Get your hands on the errata (do a Google search) and the solutions manuals as well. Best of luck!

Read this book: your bank may require it as reading if you get the job anyways (CFA institute publication on RM). Book is free!!! and actually very interesting. Also it's not a terribly tough read.

http://www.amazon.com/Practical-Guide-Risk-Management-ebook/dp/B005EZIJ22/ref=sr_1_1?s=books&ie=UTF8&qid=1414453543&sr=1-1&keywords=a+practical+guide+to+risk+management

It could very well be Navy/miltary inspired, but I only know of it from the FAA side of things, specifically FAA Risk Management Handbook (FAA-H-8083-2) - (Amazon Link).

Get the book Insurance Logic. It's written for Canadians and will explain everything you need to know about insurance. I just got it and I am starting to read through it.

My current favourite books:

Six skills and other Discussions

Staying Alive

Deco for Divers

I happen to work for a company that develops software that runs on airplanes. My job function is to help create and maintain tools that assist with ensuring said software works correctly.

(This is a simplification)
Per the FAA's FAR Part 21, you are required to follow rigorous steps and provide evidence that you followed those steps. To assist in this, an organization called the RTCA developed a number of documents, in coordination with experts in the industry that more specifically detail exactly how you have to do things.

The most important, industry standard, document for flight-worthy software that I'm aware of is DO-178 (which is currently in revision C). This document tells you what rigor you must follow in order to prove your software works as intended. The rigor is adjustable based on something called a Design Assurance Level, or DAL.

Basically, DALs are categories for software based on the impact failure of that software would have. For instance, "Failure may cause a crash. Error or loss of critical function required to safely fly and land aircraft." is considered Catastrophic and would require the highest level of rigor available in DO-178, Level A. Less critical software, "Failure has no impact on safety, aircraft operation, or crew workload.", receives Level E, and has the least rigor (but still has rigor). And there are levels B, C and D as well, covering ever increasing calamity if your software fails.

DO-178 covers verification and validation. To develop the product, there are a plethora of standards that you can employ. At least in the US, they primarily come from RTCA (the DOs), ARINC (ARINC 100-900 series documents), and MIL-STD documents (for military applications).

Some of these specifications dictate how your software must behave. For instance, my understanding (and I don't write flight-worthy software, so I might be wrong here) is that at certain DALs, you're not allowed to allocate new memory (malloc/new) at any point after an initial startup of the software. Once running, you have to have a static memory footprint.

All of this stuff is aggregated into each company's own policies and procedures. My company has their own proprietary processes for following meeting all of this. During the process, we're audited multiple times to ensure things are done correctly. It's an incredibly complex process.

I learned what I know on the job through various trainings that my company provides, through experience and through my own research. But all of that training really is intended to help you learn all of the standards and practices so that you can work day to day within them.

And this is just for flight-worthy software. There are other standards and practices for hardware, for data, for data formats, for mechanically constructed objects, etc. And that's just for aviation. Each major industry that has safety/mission-critical engineered products has their own set of standards and practices that you have to learn to follow.

Keep an eye on the automotive industry as autonomous cars are developed. That's probably the one safety critical industry that's in its infancy. I suspect much of the FAA stuff will be adopted/evaluated to apply there given the sheer safety of air travel, at least via the US/FAA (take a look here and see the last time a US originated airline suffered fatalities).

EDIT: Actually read the questions on SO:
Question 1: The difference, is in standards, practices, policies, procedures, and oversight that you MUST adhere to. There is plenty you can do to build good, reliable software that is not mission critical, you're just not required by regulation to do it.

Question 2: I think (from my experience) that they receive that training as introductory software quality assurance classes in a software engineering program in college and then followed primarily by on the job training. Also, there are plenty of companies out there that specialize in training people to the standards in their industry. I just find that those companies are usually brought in by the company you work for, not something you go get yourself.

Question 3: This is tricky. It's industry specific, for one, but it's also pricey. Every document I mentioned above costs money. Each individual RTCA DO document costs money (for instance, RTCA charges $250 for a soft copy of DO-178C on their website). The ARINC documents will be similar. But there are also books out there that cover this specialty (for instance this). And I haven't really looked, but I'm sure there are colleges out there that have degree programs specifically for safety critical software development.