Software Integrity

 

Podcast: MISRA and software testing

Standards. Whether they are advisory or compulsory, standards developed for code development promote safety, quality, and security. This is especially important in life-critical industries such as automotive and medical. One example is MISRA C which provides software development guidelines for the C programming language.

In this week’s podcast I talk with Nelson Tam, Product Marketing Manager for Coverity at Synopsys, about MISRA C and its importance to the various industries, namely automotive and medical.

First I asked Nelson what is MISRA?

Nelson Tam: MISRA started back in 1997. Back in the days, one of the automotive companies sent around a draft C coding standard to consultants asking them, “We want to write secure code in C. We want to adopt some best practices and this is our suggestion. What do you think?”

The consultants came back and said, “It’s a good start. Let’s do something better and more comprehensive.” Their response to the standard was what we now know as the very first version of MISRA. Because it was released in the year 1998 that was known as MISRA C 1998. That was the first version.

Initially, they didn’t expect a wide adoption because it was just between two companies, but people found it so useful that word started spreading around, and eventually there was a huge demand for a second version and a third version.

Where we are right now, we have MISRA C and the most recent version was released in 2012. 2012 is written in such a way where it’s very conducive for static analysis tools to implement those guidelines. That is where we stand right now.

Robert: Who is likely to benefit from MISRA? Are there particular verticals or industries that are more likely to adopt this and use it?

Nelson: Right now MISRA is really recognized as an industry standard across the automotive industry, but generally any industry or application that is safety critical will benefit from it. The reason being is that MISRA has…It’s not strictly a security coding standard, but if you adopt MISRA it does give you safety benefits.

For critical applications like automotive, they would benefit. Another industry that we see wide adoption is in the medical industry. We’ve seen lots of medical companies saying, “We wish we had a coding standard but there isn’t one for medical, so we will just take MISRA or borrow from another industry that already has something.” They adopt MISRA.

Other examples include aerospace and military, and generally speaking any established industry that uses lots of C code will benefit from MISRA.

Robert: You mentioned that it’s not a security standard necessarily, that it’s more of a safety. But in this case, it can be used for security. Can you explain the difference between safety and security?

Nelson: The C language specification and the design of the language itself is meant to be very flexible, and it’s meant to be tailored for, I suppose, high performance code. If you write your code according to the spec, it can be very high performance, but there are also things that you shouldn’t do that the spec doesn’t say that you can’t do. The spec is very broad like that.
What MISRA does is to say, “There are certain things that although is permissible by the C language standard, but maybe you shouldn’t do that, because that would make the code either not portable, or unsafe, or it has undefined behavior.”

When we talk about safety and when you look at the way that MISRA defines safety, a lot of it is about undefined and ambiguous behavior because the specification doesn’t say when you write code like this, what will happen in the machine.

When that happens when you have ambiguous behavior, you can’t reason about it. You can’t say, “Oh, I know that the car or the medical device went to A, B, or C, because the spec doesn’t necessarily define that.

As a result, the device goes into an unknown state, and sometimes the implications can be unpredictable. That’s what we mean by safety, generally. MISRA is primarily a safety and portability standard.

The reason why I brought security into this is because…There’s two reasons. Firstly, a safety bug can also have security implications.

When we talk about security we’re taking about things like when you have input that’s not trusted from a user and you do something with it, can it affect the underlying system in such a way that the system may fail or data may leak out, generally things like that.

If a malicious user wants to sabotage the system, are they able to? Sometimes they will use safety vulnerabilities to come to that, to achieve that aim, but sometimes they may use other things. Those other things is what we mean by security guidelines or security vulnerabilities.

One thing that I should note is that just two months ago in April 2016, the MISRA Working Group actually released 14 new guidelines. The interesting thing about these guidelines is that they are a departure from the existing standard where the previous guidelines were, like we said, safety focused with security side benefits, but these ones are really focused on security guidelines.
Data [inaudible 06:14] , data flow related problems, and the fact that you need to sanitize the input, all those things are covered by the new 14 rules. You can see how MISRA is evolving from something like more safety and portability focused into security focused, which is a really good development.

You can see that in the industry that is where people are going, that is what the demand is. It would generally lead to just much better code overall. Yes, we’re really encouraged to see those kinds of changes in the industry.

Robert: You mentioned that the MISRA C 2012 release was more compatible with static analysis tools. Can you explain why that might be?

Nelson: If you look at some of the older MISRA versions there were a significant amount which is…they are very good guidelines, but they are more oriented towards process and documentation, which means that those rules need to be checked manually.

The way that static analysis works is that it looks at source code and it doesn’t really look at documents and processes. In the older MISRA versions, you can use static analysis and they would get you very far, but it wouldn’t be close to 100 percent. The static analysis tools would not be able to cover 100 percent of the older MISRA coding standard guidelines.

In 2012, they’ve recognized that static analysis tools can be very useful in implementing these. What they’ve done is to start rewriting some of those rules, getting more conducive to be implemented at a source code level. That is why it’s becoming more compatible with static analysis.

I might add that it’s not 100 percent. Out of the 159 rules in 2012, there are three of them that are documentation and process oriented, but nonetheless you can still do other rules using static analysis tools. Our belief is that the authors have really got it right.

MISRA compliance, checking for MISRA violations is a tedious process, is a time consuming process. The more leverage you can get out of using tools that’s run on a computer, the less time it takes for a human to implement that, which would really just increase the cycle that we can perform compliance on.

The more convenient it is, the easier it is for industry to adopt that and, again, overall it would lead to better code to be used in the industry, better code to be implemented in the real world, and the world is a better place.

We think that static analysis tools have a lot of contribution to make in the compliance space and we’re really glad that MISRA is going in this direction.

Robert: With version 8.5, the Synopsys part of Coverity will provide full support for MISRA through 2012. How is this solution different than what is offered by the competitors today?

Nelson: There are quite a few aspects, actually. We mentioned that certainly we provide pretty much…when we say full coverage, where we’re talking about the static analysis, the rules are statically checkable.

Firstly, Coverity provides full coverage. Not all our competitors do that even though some of them do partial coverage of certain rules. We really are serious about supporting the entire standard. That’s the first distinction, is the breadth of coverage. The second distinction, it’s the depth. When we are writing these rules we are writing custom rules for every single MISRA guideline.

Some of our competitors take the approach that we have existing rules that cover somewhat the MISRA guidelines. We will simply use those rules to implement that. They don’t really look at whether the coding standard is…that each component of that rule is covered comprehensively.

They don’t necessarily look at that, but we do. The quality and depth of our checks is really written in such a way where it’s compliance focused. The third distinction is that our tool is actually designed not just with one company or one vendor in mind but really to look at the entire supply chain.

In automotive industry, you don’t just have one company doing all the software work. In fact, there’s an ecosystem of dozens or even hundreds of companies all working towards and contributing towards the same product.

When we talk about MISRA compliance it’s not good enough for just a final vendor or final OEM to be compliant. You really need the whole chain to be compliant because after all every participant in the chain acts upwards to it, and any failure in one of the components can trickle up.

With that supply chain in mind and with that kind of complexity in mind, our Coverity tool is really designed so that different people in the same ecosystem can communicate their compliance status to each other. This is what the industry needs, and this is how we are set apart from the other competitors.
I would say that to summarize the breadth of our checks, the depth of our checking implementations, and also our focus and our vision of looking at the entire software supply chain, is what sets us apart from the other competitors.

Robert: Is there anything else that I haven’t asked that you would like to bring up today?

Nelson: I think that at a bigger picture level we are not only committed to supporting MISRA C 2012 but also all the other coding standards that are widely used in industry. The next one we’re looking very closely into is MISRA C 2004 because a lot of companies in the industry are still using that.

Going forward we will be looking very closely at other ones, too. The ones that are off the top of my head are things like CERT Secure C, things like JSS, things like the IEC and ISO Secure C Standard. All of these are making really large contributions to industry. We are looking at them with very keen interest.

For those who are listening, please be assured if you are looking for compliance solutions, Synopsys is actually looking at that with a lot of keen interest. We will be totally behind this industry effort.

Robert: Thank you, Nelson, for your time. I appreciate it.

Nelson: Thank you, Robert.