MISRA guidelines exist for a simple reason
C and C++ give developers considerable freedom, and some of that freedom creates risk in vehicles, infusion pumps, factory controllers, and other safety-critical systems. The guidelines restrict language features that are ambiguous, undefined, or easy to misuse.
Most engineers accept the goal. What they dread is the process: audit spreadsheets, thousands of warnings, and a late scramble before a safety review. It doesn't have to work that way. When rule checking becomes part of daily development, compliance stops being a separate event and becomes a routine engineering practice.
What MISRA Actually Requires
The standards you will encounter
MISRA C provides long-standing guidance for C, while MISRA C++:2023 covers modern C++. The MISRA C++:2023 standard contains 179 guidelines, so adopting it requires a structured plan rather than an informal review.
For C projects, MISRA C:2023 consolidates the earlier MISRA C:2012 guidance and its amendments. This includes guidance for multithreading and atomic operations introduced with C11 and C18. If your firmware uses threads or atomics, make sure the selected ruleset covers those language features.
Rules, directives, and tool limits
Two distinctions help define the work. Rules generally describe requirements that can be checked against source code. Directives may depend on design records, requirements, or other evidence outside the code, so an analysis tool can assist without completing the review.
The second distinction is decidable versus undecidable. An analyzer can settle some checks with certainty. Other checks require assumptions or human judgment. MISRA Compliance:2020 states that a realistic process for checking code against MISRA requires at least one static analysis tool. It doesn't claim that a tool is sufficient on its own. Human review and documented decisions remain essential.
Why Static Analysis Does the Heavy Lifting
What tools handle well
Automated checkers are well suited to repetitive checks involving names, types, prohibited constructs, implicit conversions, unreachable code, and patterns that are legal but difficult to reason about. Whole-program analysis can also find issues across translation units that a single-file review would miss. When integrated into an editor, the analyzer can report a problem soon after it is introduced, while the relevant code is still fresh in the developer's mind.
What tools cannot do
Static analysis cannot find every class of defect automatically, and it works best alongside human review. Expect some false positives and plan for undecidable rules to require a recorded decision. Configuration can also drift when compilers, targets, or language options change. Validate the analyzer against the project's actual build rather than relying on generic defaults.
A Workflow You Can Ship With
Choose and record a baseline
Select one ruleset version for each project and document it. For C, use the MISRA C edition and guidance that match your language level. For modern C++, that may be MISRA C++:2023. Changing baselines during active development can create substantial rework, so revisit the choice only at planned milestones.
Configure once and enforce consistently
Configure the analyzer with the same compiler, target, and language options used by the build. Integer widths, language variants, preprocessor definitions, and compiler extensions can all affect results. Enable whole-program analysis where appropriate. Store the configuration in version control so developers, build agents, and auditors use the same settings.
Put checks where developers already work
Analysis that runs only at night can turn findings into a backlog. Run a fast subset in the IDE, add a pre-commit or pull request check, and reserve the full scan for CI. Establish a baseline so accepted legacy findings do not block every change, then gate new issues according to an agreed severity policy. The principle holds across languages. Teams applying static analysis in CI/CD pipelines outside the embedded world reach the same conclusion, which is that automating the check matters more than which analyzer runs it.
Triage findings as a team
Sort findings by risk rather than rule number. Group issues that share a root cause so one code change can resolve several warnings. Assign ownership by module instead of distributing individual alerts. A short weekly triage session is usually more manageable than a quarterly cleanup effort.
Handle deviations deliberately
Sometimes a documented deviation is the appropriate decision. MISRA Compliance:2020 treats deviation permits as formal records, not convenient exceptions. Follow three basic practices:
- Do not approve a deviation solely for convenience or schedule pressure.
- Consider reasonable alternatives and record why they were rejected.
- Document the rule, scope, rationale, and approver, then review the decision at the next milestone.
Produce evidence, not just green builds
An auditor may need rule-mapped reports, analysis configuration, deviation records, tool versions, and the relevant source revision. A screen showing zero findings isn't sufficient evidence. A reproducible report tied to a specific commit is much more useful.
A Short Checklist for Choosing a Tool
Static analysis tools vary in their support for safety-related development. When comparing options, consider:
- Language and dialect support that matches your compiler, including required embedded extensions.
- Whole-program analysis rather than only per-file checks.
- IDE and CI integrations that fit the team's existing workflow.
- Support for partial code when the complete project cannot be built.
- Reports with rule mapping, deviation tracking, and audit-ready exports.
- Mappings to related standards such as CERT C or C Secure.
- Licensing that fits the development team and build infrastructure. When public pricing isn't available, include vendor discussions in the evaluation schedule.
Where AI Helps and Where It Does Not
AI assistance is appearing in analysis tools. Parasoft C/C++test 2025.1 introduced an in-product AI Assistant available from the Parasoft menu. Parasoft C/C++test 2026.1 adds AI-assisted verification intended to automate parts of remediation and support compliance workflows.
Used carefully, these features can help explain why a rule was triggered, suggest a first-draft correction, or address a repetitive pattern across several files. Confirm which Parasoft capabilities are included in your license, and check organizational policies before enabling any model integration.
A suggested change isn't automatically safe or compliant. Each change still needs code review, appropriate testing, and analysis in the context of the rule. Human judgment is particularly important for undecidable rules, where the developer's intent and system behavior affect the decision.
Putting It Together in a Real Toolchain
For teams evaluating a commercial platform that centralizes rulesets, integrates with IDEs and CI, and produces mapped reports for MISRA compliance, Parasoft is one option to assess. Parasoft C/C++test supports standards including MISRA, CERT, and AUTOSAR C++14, which can be useful when one codebase is subject to several requirements.
Certification status is another practical consideration. Parasoft C/C++test is TÜV SÜD-certified for use with standards such as ISO 26262, IEC 61508, and IEC 62304. That certification may simplify parts of a tool qualification assessment, although teams must still confirm that the selected version, configuration, and use case fall within the relevant certification scope. No tool guarantees a successful audit.
A Quick Look at the Alternatives
Other tools may fit different project needs. PVS-Studio is a proprietary analyzer with MISRA support. Polyspace uses abstract interpretation to identify or prove the absence of certain runtime errors in C, C++, and Ada, and it can check coding standards. CodeSonar, from CodeSecure, is another option used for safety-critical C and C++. Compare two or three tools against your actual repository, build configuration, and reporting needs rather than relying only on sample projects.
Conclusion
MISRA adoption is partly a scheduling challenge. Teams that struggle often postpone checking until the end of development. A more reliable approach is to run the analyzer regularly, prevent new findings from accumulating, review difficult cases as a group, and document deliberate exceptions. Choose a baseline, match the analysis configuration to the build, provide feedback early, and maintain the evidence as the code changes. The eventual audit can then summarize work already completed instead of becoming a separate cleanup project.
FAQs
What parts of MISRA can an analyzer check automatically?
An analyzer can check many requirements that are evident in source code, including prohibited constructs, type and conversion issues, and structural patterns. Directives that depend on design documents and rules classified as undecidable still require human judgment and a recorded decision.
How often should checks run in CI?
A fast subset can run on every pull request, with a full scan scheduled nightly or at another suitable interval. Pull request checks prevent common new issues from entering the codebase, while full scans can cover slower whole-program analysis.
How do deviation permits work?
A deviation permit records that a guideline isn't being followed in a defined location. It should state the reason, scope, risk assessment, and approver. Deviations are intended for cases where compliance is impractical or could create a worse outcome, not simply to save time. Review them again at project milestones.
Does MISRA align with CERT C or C Secure?
Published mappings connect these standards. Addendum 2 to MISRA C:2023 maps its coverage against ISO/IEC TS 17961. Addendum 3 maps MISRA C:2023 against the SEI CERT C Coding Standard. These mappings can reduce duplicate review work, but they do not make the standards interchangeable.
