Choosing a MISRA C/C++ Static Analysis Tool for Embedded and Automotive

MISRA C and MISRA C++ are coding guideline sets used across embedded and automotive software to keep C and C++ code safe, secure and portable. They are published by The MISRA Consortium Limited, an independent not-for-profit body, whose own mission statement describes its purpose as producing practical guidelines for the safe and secure application of both embedded control systems and standalone software. Most teams that adopt MISRA do so because a customer, a functional safety standard, or an internal quality process requires it.

Picking the tool that will enforce those guidelines is not just a feature comparison. MISRA itself publishes a separate document, MISRA Compliance:2020, that sets out what a credible compliance claim actually requires beyond a clean static analysis report: a disciplined development process, a record of which guidelines apply, and a documented, auditable way of handling the violations that any real codebase will have. A tool that cannot support that process is not doing the job, however many rules it claims to check.

This article works through what MISRA C:2023 and MISRA C++:2023 actually are, what the guideline categories mean for how a tool should be configured, what ISO 26262 and IEC 61508 expect of the tooling itself, and what to check before buying a static analysis tool for embedded or automotive C/C++ code.

What MISRA C and MISRA C++ actually cover

MISRA C:2023 (Third Edition, Second Revision) is described on MISRA's own product page as guidelines for the use of the C language in critical systems. It was updated in April 2023, incorporating the text of Amendments 2 to 4 and Technical Corrigendum 2, and it supersedes all earlier MISRA C editions published in 2019, 2012, 2004 and 1998. MISRA C++:2023 was published separately, in October 2023, and specifically targets the C++17 language version as defined by ISO/IEC 14882:2017.

Buyers should also know that MISRA has since moved on again: according to MISRA's own FAQ page, MISRA C:2025 was published to coincide with the Embedded World Conference in Nuremberg in March 2025 and is now the current edition. Every tool vendor covered in this article still documents its coverage against MISRA C:2023 (or older editions) rather than MISRA C:2025, which is exactly the kind of detail worth confirming directly with a vendor before you rely on a checker list.

Mandatory, Required and Advisory: the categories that drive tool configuration

Every MISRA guideline carries a category, and that category decides how a tool should treat a violation. MISRA Compliance:2020 defines three:

A project can also formally re-categorise guidelines through a guideline re-categorization plan (GRP), for example promoting an Advisory guideline to Required. The rules are one-directional: a Mandatory guideline can never be downgraded, and a Required guideline can never become Advisory or be dropped altogether ("Disapplied"). A static analysis tool that only offers a single severity level per rule, rather than letting you map each finding to your project's own GRP, will not fit this model well.

A MISRA compliance claim is a process claim, not a clean scan

MISRA is explicit that the phrase "MISRA compliant" needs careful definition. Its compliance page states that a claim of compliance only has meaning once you can establish five things: use of a disciplined software development process, exactly which guidelines are being applied, the effectiveness of the enforcement methods, the extent of any deviations, and the status of any code developed outside the project.

In practice this means real paperwork, and a tool needs to help produce it, not just list violations:

• Deviation records, which MISRA Compliance:2020 says must include the guideline being violated, a description of the circumstances, the reason the deviation is needed, background context, and any risk-assessment precautions.
• A guideline enforcement plan (GEP), listing every guideline and how compliance with it is checked, including the tool version, its configuration, and evidence that it can actually detect violations of that guideline.
• A guideline compliance summary (GCS), which grades compliance per guideline category rather than as one pass or fail number: a Required guideline, for example, is reported as Compliant or as Deviations, while an Advisory guideline can also be reported as Violations.

MISRA Compliance:2020 also lists what a supplier must hand over to support a compliance claim: the guideline enforcement plan, the guideline compliance summary, details of any approved deviation permits used, and deviation records for every violation of a guideline categorised as Required. A tool's reporting output is only useful for MISRA purposes if it can feed into these four artefacts.

What ISO 26262 and IEC 61508 expect of the tooling itself

Two functional safety standards sit behind most automotive and industrial MISRA requirements. ISO 26262-8:2018, "Road vehicles - Functional safety - Part 8: Supporting processes", specifies requirements that explicitly include confidence in the use of software tools and qualification of software components, alongside configuration management, verification and change management. IEC 61508-3:2010, the software requirements part of the IEC 61508 functional safety series, goes further and states that it "provides, in conjunction with IEC 61508-1 and IEC 61508-2, requirements for support tools such as development and design tools, language translators, testing and debugging tools, configuration management tools".

MISRA Compliance:2020 makes the same point from the coding-guideline side: "Some process standards, including IEC 61508, ISO 26262 and DO-178, require the qualification of compilers and static analysis tools in some situations." That single sentence is the reason vendors publish TUV certificates and qualification kits, and it is worth reading carefully: it is the safety standards that impose the tool-qualification requirement, not MISRA itself.

Selecting a MISRA static analysis tool: what to check before buying

Coverage of the rule set

Ask for a precise number, against a precise MISRA edition, and ask separately for MISRA C and MISRA C++ - vendors' coverage can differ sharply between the two. Klocwork's own product page lists coding-standard taxonomies that include MISRA C 2004, MISRA C 2012, MISRA C 2023, MISRA C++ 2008 and AUTOSAR C++ 14, alongside CERT and CWE for security. Understand by SciTools publishes edition-by-edition coverage figures: for MISRA C:2023 it reports 95% of the guidelines it tracks for that edition (207 of 217), split into 96% of Required guidelines and 91% of Advisory guidelines; for MISRA C++:2023 it reports 93% (164 of 176). SonarQube takes a different shape entirely: its Enterprise and Data Center editions claim 100% coverage of all 179 MISRA C++:2023 guidelines, with 174 of those checkable directly inside the IDE and the remaining 5 requiring a full project-level scan. Its MISRA C (as opposed to C++) support is much newer - as of SonarQube Server 2026.4 it covers a first batch of 36 MISRA C guidelines, with the vendor describing full coverage as still in progress.

Deviation workflow support

Given how central deviation records, the GEP and the GCS are to an actual MISRA compliance claim, ask a vendor to show you, not just tell you, how the tool records a deviation against a specific guideline, how it distinguishes Mandatory, Required and Advisory findings, and whether it can export something close to a guideline compliance summary.

Tool qualification evidence

Because ISO 26262 and IEC 61508 place qualification requirements on the tooling itself, check exactly what a vendor's certification covers. Klocwork states it is independently certified by TUV-SUD for ISO 26262 up to ASIL D, IEC 61508 up to SIL 4, EN 50716 up to SW-SIL 4, and IEC 62304 up to Software Safety Class C, in addition to ISO 9001 and ISO 27001 certification. Understand states it has been certified by TUV SUD and separately markets itself as certified for ISO 26262, IEC 61508 and EN 50128 as a support tool. Ask for the certificate itself, and for the specific tool version and ASIL/SIL level it covers, since certifications are usually tied to a release.

CI/CD integration and traceability

A finding is only auditable if it can be traced back to a specific guideline and edition. Klocwork's checker identifiers do exactly this: a checker such as MISRA.STDLIB.MUTEX.DBL_LOCK.2023 embeds both the MISRA category and the edition year in its own name. On the reporting side, SonarQube's quality gates can block a merge when non-compliant code is detected, which is useful for enforcing a GCS-style policy automatically rather than reviewing it after the fact.

Static analysis alone does not satisfy a safety standard

Static analysis checks source code without running it, which is exactly what MISRA guideline enforcement calls for, but functional safety standards also expect dynamic evidence. As QA Systems puts it on Cantata's own product page, "international software safety standards require evidence of low level (unit and integration) testing to obtain certification for the device software", and its own description of a verification pipeline places coding-standard compliance checking first, automated dynamic unit and integration testing next, and proof of the absence of run-time errors after that. Cantata sits in the middle of that sequence: it automates C/C++ unit and integration test generation, execution and results reporting on host and embedded target platforms, separately from any static MISRA checker.

Cantata is independently certified by SGS-TUV SAAR GmbH for what QA Systems calls the main software safety standards, including ISO 26262, IEC 61508, IEC 62304, IEC 60880 and EN 50128/50657, and it is described as qualifiable for DO-178C. Standard-specific certification kits are provided free of charge; for standards where a blanket tool certification is not permitted, QA Systems instead offers separate tool qualification kits, since the tool then has to be qualified again for each project, DO-178B/C being the example given on its own site.

What MISRA's own statement on tool "certification" actually says

MISRA does not run a tool certification scheme itself, and it says as much in its own wording rather than by silence: the copyright notice in MISRA Compliance:2020 states that "no endorsement or recommendation of these products by MISRA is implied" for any product or brand referenced in its materials. The certifications and qualification kits described above (TUV-SUD, SGS-TUV SAAR) are issued by independent third-party bodies against standards such as ISO 26262 and IEC 61508, commissioned separately by each vendor. They are not badges MISRA itself awards.

What MISRA does offer is guidance on how to build confidence in a tool yourself. MISRA Compliance:2020 suggests performing documented validation testing, assessing the tool supplier's own development process, and reviewing the tool's track record over time, and it is candid that no tool can be perfect: some MISRA rules are formally undecidable, meaning no static analysis tool, however capable, can guarantee a definite yes-or-no answer for every piece of code. A vendor that is upfront about this is generally more trustworthy than one that claims otherwise; Klocwork's own documentation, for instance, states plainly that "software verification tools cannot, on their own, ensure compliance with standards, for example, ISO 26262, they can aid developers looking to demonstrate process compliance".

Next steps

Before choosing a tool, write down which MISRA edition (C and C++ separately), which guideline categories, and which downstream standard (ISO 26262, IEC 61508, IEC 62304 or another) actually apply to your project, since that list determines which vendor claims are relevant to you and which are not. Ask each vendor for a current coverage figure against that specific edition, a copy of their qualification or certification material, and a look at how deviations and the guideline compliance summary are handled in the tool, not just in the sales deck.

If it would help to work through this against your own codebase and toolchain, SecOpsTool can set up a scoping call and, where useful, a trial of a MISRA-capable static analysis tool such as Klocwork alongside your existing CI/CD pipeline.

Questions Buyers Ask

Sources

Primary documents this article is based on. Regulatory clauses and product statements above are taken from these pages.

• MISRA C:2023 product listing
• MISRA C++:2023 product listing
• MISRA Frequently Asked Questions
• MISRA Compliance:2020 (achieving compliance with MISRA coding guidelines)
• ISO 26262-8:2018 abstract, Supporting processes
• IEC 61508-3:2010 abstract, Software requirements
• Perforce Klocwork product page
• Klocwork IEC 61508, IEC 62304, EN 50716 and ISO 26262 qualification
• Understand by SciTools, MISRA C/C++ compliance
• Sonar support for MISRA C++:2023 guidelines
• Sonar Community: MISRA C compliance, first rules now available
• QA Systems Cantata product page