If you've haven't heard about Apple's security flaw registered as CVE-2014-1266 on apple website, you probably were on planet Mars.
Basically, it was unsafe to use https connections. I couldn't help but write an article about this!
Components dealing with secured connections are abolutely critical. Applying rigorous development process is the best chance to avoid any trouble with these components.

We saw in the first article of this series, what is a SOUP and what is not a SOUP, according to IEC 62304.
Then we continued in the second article by having a look at OS's and drivers.
Let's now see how to deal with runtimes.

We've seen in the last article, what is a SOUP and what is not a SOUP, according to IEC 62304.
We've also seen that a lot of 3rd party software are SOUPs, to begin with OS, drivers, runtimes, Just-In-Time (JIT) compilers and frameworks.
How to deal with those to be compliant with IEC 62304?

IEC 62304 requires to split architecture of class C (mission critical) software into software items and software units. Software units are software items that can't be split into sub-items, according to the standard. Okay. But how to decide that an item can't be split into sub-items, and is a unit?

In two previous articles, I talked about the differences of bugs, software failures, and risks.
I left the discussion unfinished about the probability of occurence of a software failure or a defect.
I think that assessing the probability of occurence of a software failure is a hot subject. I've already seen many contradictory comments on this subject. It's also a hot subject for software manufacturers that are not well used to risk assessment.