Introducing the MISRA C coding standard to an existing codebase

The intent of the Motor Industry Software Reliability Association (MISRA) The C coding standard was to define a subset of the C language that minimizes the possibility of errors. Although originally intended for safety critical applications in the automotive market, it is used in other areas such as medical and aerospace. Some software teams also use the standard as a way to improve the quality and security of their code, but do not necessarily require the standard to comply with a safety or security standard. MISRA C is a well known and respected standard and it is spreading to other markets.

MISRA’s goal is to provide better code during the development process. Applying MISRA rules to code already written, tested and/or deployed is not an easy task. The question is whether it makes good business sense to make changes to an existing code base that has been proven to be reliable, with the risk of introducing new problems with the changes. This article examines some pragmatic approaches to adopting MISRA incrementally using static application security testing (SAST) tools such as CodeSonar by Gramma Tech.

What is the goal ?

The approach to adopting a new coding standard depends on the requirements of the new system.

  1. If the requirement is to achieve full compliance with MISRA, then the existing codebase will need to be made compliant. CodeSonar can certainly help in this situation, but that is not the focus of this blog post.
  2. If instead MISRA is used to provide better code in the future, this article offers an interesting approach.

MISRA C Guidelines

It is important to realize that not all MISRA C guidelines are created equal. Guidelines are either rules or directives, the difference being that the rules are completely described in the standard and compliance with a rule can be checked, usually automatically with static code analyzers. A directive is less defined and requires additional information, usually provided during an audit, to ensure compliance. For the purposes of this article, we’ll be talking about the MISRA C guidelines as standard coding rules.

Coding standards generally categorize rules by severity and MISRA C is no different. The MISRA C rules fall into three categories, mandatory, required and advisory. As expected, the mandatory rules are the most critical and the advice less so. If the plan is to use MISRA C to avoid the most egregious errors, your team may decide to ignore the advisory rules, at least initially.

The first step in adopting MISRA C is to review the rule set and select the advisory rules most applicable to the current application, creating your own MISRA subset. This is an entirely legitimate approach that newcomers overlook, believing it to be an “all or nothing” set of rules and, therefore, overwhelming. If your organization plans to use MSRA C as the basis for your own custom coding standard, without the need for full MISRA C compliance, additional selection is possible.

“Stop the Bleeding”

Of course, applying MISRA C to an existing codebase can be a big investment, you may have thousands of violations to assess, which isn’t always helpful because your code is already tested and shipped. Changing working code to conform to a coding standard isn’t always a good investment. What may be more financially viable is to start by ensuring that your new code is MISRA C compliant.

The way to achieve this with CodeSonar is to run a scan on your entire source code base and highlight violations. You can then use these results as a basis for comparison. We go into more detail about adopting SAST in existing code in this Publish. This comparison now only highlights MISRA violations in new code developed after the baseline. This new code can either be in new files or even added to existing files. Violations of MISRA rules can be passed to the developer directly in their IDE, which “stops the bleeding”.

A pragmatic approach to adopting MISRA C

A way for developers to make it easier to use a new coding standard means some preparation ahead of time to reduce the risk of the team being overwhelmed with reports. The following steps provide a quick summary of the necessary steps:

  1. Define a set of rules for the project: It is possible that you already have a coding standard and as such you may be considering MISRA C as a way to extend what you have. If not, and full compliance isn’t the end goal, it’s a good idea to decide which rules the team plans to adopt.
  2. Configure CodeSonar to support the ruleset defined by the team. It makes sense, of course, to also keep various bug and security vulnerability rules enabled.
  3. Use filtering to focus on the most critical breaches. Once a benchmark report has been generated, CodeSonar has powerful filtering and saved search capabilities to help developers focus on the most critical violations first. It is also possible to filter only changes made to the latest version, to evaluate violations by type, severity or by file.
  4. Focus on the new code first. Depending on the preferred approach, the baselines report can be filtered by setting the status of existing violations to “defer” or simply filter new reports based on deltas between versions. In both cases, the evaluation focuses on changes made to the code or new code written.
  5. Assess and prioritize violations. It’s important to assess violations in new code as they arise, and by that we mean analyzing whether the violation is real, deciding whether it needs to be fixed, and assigning a priority to the fix. It shouldn’t be too expensive when you’re focusing on new code. However, the team can be overwhelmed if violations are not handled at each iteration.
  6. Evaluate existing code, time permitting, in order of severity. If the team decides to look at the state of the existing code (before the baseline and before we “stop the bleeding”), it makes sense to consider the most serious violations first. This is where CodeSonar’s powerful search, sort and filter capabilities come in handy. Assessments can be made first on mandatory rules, for example, and fixes can be assigned and prioritized.


Adopting MISRA C to an existing project that does not require official compliance can still be a daunting undertaking without a thoughtful approach. This pragmatic approach focuses on new code, initially, and evaluating coding standard violations in order of severity. CodeSonar supports both MISRA C and configuration options, as well as filtering and search functionality that makes this pragmatic approach a reality for software developers.

To learn more, we invite you to download and read this white paper, “Accelerating MISRA Automotive Safety Compliance with Static Application Safety Testing.”

*** This is a syndicated blog from the Security Bloggers Network of Blog written by Christian Simko. Read the original post at:

Comments are closed.