Automating MISRA C Static Analysis in the Embedded CI/CD Pipeline

How to move MISRA C checking out of the pre-release scramble and into every pull request, with notes on Coverity, Klocwork, QAC and the rest.

By Subeesh Sivanandan, Founder & CEO, Stonetusker Systems · Updated October 2026 · Est. reading time: 14 minutes

Why MISRA C checks belong in CI, not in a pre-release scramble

Most embedded teams know this story. The firmware gets written over a year or so, the analyzer license arrives late, and two weeks before design freeze somebody runs it across the whole tree for the first time. Thousands of findings come back.

Nobody can fix that much in two weeks. So deviations get written in bulk, the justifications get copy-pasted from one to the next, and the compliance report ends up describing what the team hoped the code looked like.

Putting the check on every pull request changes the economics. A finding in a 40 line diff gets fixed by the person who still remembers why they wrote the line, usually in five minutes. The same finding discovered eight months later needs somebody to re-read the context, guess at the original intent, and argue about whether it's a real problem.

There's a second benefit that gets less attention. A pipeline that checks every commit leaves dated, per-commit evidence behind. When an assessor on an automotive or medical program asks how you know the code at release 2.3 followed your coding standard, "we ran the tool the week before" is a weak answer. A job log tied to the release tag is a strong one.

What static analysis can and can't check in MISRA C

MISRA C splits its guidelines into directives and rules, and every guideline is categorized as Mandatory, Required or Advisory. MISRA C:2012 has 16 directives and 143 rules. Later editions, including the 2023 consolidation, build on the same structure, so check which edition your customer or assessor names in the contract. A lot of programs still reference 2012.

Rules are either decidable or undecidable. A decidable rule, such as not ignoring the return value of a non-void function (Rule 17.7), can be checked exactly. An undecidable one depends on runtime behavior the tool can only approximate, so you get false positives, quiet misses, or both.

Some directives can't be tool-checked at all. Directive 3.1 wants all code traceable to documented requirements, and no analyzer knows what your requirements say.

This shapes how you present compliance. MISRA Compliance:2020 asks for a Guideline Enforcement Plan, which is where you state, guideline by guideline, whether enforcement is by tool, by review, or by both.

A four-tier pipeline for MISRA C static analysis

One analyzer run can't serve every purpose. A whole-program, cross-file analysis is the only way to catch things like duplicate external definitions across translation units, and it's slow. Run it on every pull request and developers will route around it, which usually means pushing "wip" commits to dodge the gate.

So split the work by how fast the answer is needed.

Tier 2 is where most of the culture lives. Keep it under ten minutes, make the failure message say which guideline broke and on which line, and developers will treat it like a compiler error. Make it vague or slow and they'll treat it like a tax.

Tier 3 catches what tier 2 can't see, and the findings it produces should go into the same tracker as bugs, with an owner. A nightly report nobody reads is worse than none, because it makes the team think the problem is handled.

Make the analyzer see your real build

Most false results in embedded static analysis come from one root cause: the analyzer parsed different code than the compiler did. A missing -D flag turns off a whole block of the firmware. A host compiler config instead of the cross-compiler's means int is the wrong size, and the essential type rules (the Rule 10 family) start reporting nonsense.

There are a few practical ways to capture the real build.

• CMake projects: set CMAKE_EXPORT_COMPILE_COMMANDS=ON and hand the resulting compile_commands.json to the analyzer.
• Plain Makefiles: wrap the build with bear to generate the same file, or use the vendor's own wrapper (kwinject for Klocwork, cov-build for Coverity, cpptestscan for Parasoft).
• Yocto: run the analysis against the recipe's worked source with the recipe's own flags. Doing it on a checkout outside BitBake almost always means wrong include paths.
• Vendor compilers (IAR, Keil, TI, ARM Compiler): configure the analyzer for that compiler, including extension keywords like __interrupt and pragmas, or it'll choke on the headers.

Then there's the license problem, which nobody mentions in the datasheet. Most commercial analyzers use a floating license server. CI runners need a network route to it, and if ten pipelines start at once, the eleventh job waits for a seat or fails. Cap the concurrency on the analysis jobs, or you'll chase phantom pipeline failures for a month.

Also pin the analyzer. Build it into a container image with a fixed tool version and a ruleset file in version control. A silent analyzer upgrade can add checkers overnight and fail every open pull request on Monday morning.

Legacy code: baseline first, burn down later

Switching on MISRA C for a ten-year-old codebase and failing the build on everything would stop all merges by lunchtime. The workable approach is a baseline.

Run the full analysis once and store the result. From then on, the pull request gate fails only on findings that don't appear in the baseline. Old debt stays visible but doesn't block anyone, and new debt is refused at the door.

Line numbers shift whenever somebody edits a file, so fingerprint each finding on something more stable: the file, the rule ID, and the text of the offending line. Most commercial tools have a built-in way to show only new findings. If you're using something simpler, a short script does the job. Here's a sketch of a GitLab job, with cppcheck standing in for whatever analyzer you actually run:

misra-pr:
  stage: analyze
  image: registry.example.com/fw/analyzer:2026.09   # pinned analyzer and ruleset
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  script:
    - cmake -S . -B build -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
    - cppcheck --project=build/compile_commands.json --addon=misra.json --xml 2> findings.xml
    - python3 ci/new_findings.py --baseline ci/misra-baseline.json --current findings.xml --fail-on required,mandatory
  artifacts:
    when: always
    paths: [findings.xml]

Burn-down order matters. Mandatory guidelines allow no deviation, so those go first. Required guidelines can be deviated only through a formal, recorded process, so fix what's cheap and document what isn't. Advisory guidelines can be disapplied with a recorded rationale, which makes them the lowest priority.

One more rule worth writing down early: touching a file doesn't oblige the author to fix every old finding in it. Only the ones they introduced. Otherwise a two-line bug fix turns into a 400-line cleanup nobody wants to review.

Deviations and third-party code

A deviation is a documented, approved reason for breaking a Required guideline in a specific place. It isn't a way to make the red go away. Each record should carry the guideline, the location, the rationale, a short risk assessment, the approver, and a review date.

Keep the register in the repository, and let CI enforce it. Fail any build where a suppression comment in the source has no matching deviation ID in the register. Put the register and the suppression syntax under CODEOWNERS so a quality or safety owner has to approve changes. That single check stops the slow drift where suppressions pile up and nobody remembers why.

Vendor code is the other sore spot. HAL and SDK drops from chip vendors often aren't MISRA clean, and rewriting them is rarely sensible. MISRA Compliance:2020 has a concept called adopted code for this situation. Record the scope, state what standard the code was written to, and either analyze it with a relaxed profile or exclude those paths with a written rationale.

A thin adapter layer between your application and the vendor HAL, written to the full standard, keeps the boundary clean. Don't park your own code in a directory called vendor to hide it from the analyzer. Assessors check the exclusion list first.

Comparing MISRA C static analysis tools: Coverity, Klocwork, QAC and others

No single tool wins everywhere. Prices move and change by quote, so none are listed here, and vendors adjust product names and MISRA edition coverage often. Check current claims with each vendor, and check them against your own code.

IAR C-STAT, CodeSonar and Axivion also appear on many shortlists, especially where the toolchain vendor or the architecture-checking angle matters.

A note on Black Duck

People often ask whether Black Duck is the tool for MISRA. It depends which product you mean. After Synopsys sold its software integrity business in 2024, the new company took the Black Duck name, and Coverity now sits under it. Coverity is the static analyzer that checks your code for MISRA violations and defects.

Black Duck SCA is a different product. It scans the open source components in your build for licenses and known vulnerabilities, and it doesn't check MISRA rules at all. It still matters to the same buyers, because SBOM expectations from medical regulators and the EU Cyber Resilience Act are pushing teams to track components, but treat it as its own pipeline stage.

How to choose without a six-month evaluation

Take your ugliest module, the one with inline assembly, vendor headers and compiler extensions, and run two candidate tools on it for two weeks. Measure four things: how many of the first 200 findings were real, how long a PR-sized run takes, how painful build capture was, and how the license behaved under parallel CI jobs. Those four numbers settle most arguments.

A 90-day rollout playbook for MISRA C in CI

This is the sequence that works for one firmware repository with a build that already runs in CI. Multiple repositories repeat the same steps with the first one as a template.

1. Choose the guideline set and write the compliance planPick the MISRA edition, decide which guidelines are enforced by tool, by review or by both, and record the categories you'll treat as Mandatory, Required and Advisory. Weeks 1 to 2.
2. Make the build observableGenerate a compile database or use the vendor's build capture, and put the analyzer in a pinned container with its ruleset and license configuration under version control. Weeks 2 to 4.
3. Run a baseline analysis and freeze itAnalyze the whole project once, review a sample of findings to tune out obvious false positives, and commit the baseline file. Weeks 4 to 5.
4. Gate pull requests on new findings onlyAdd the incremental job to every pull request, fail on new Mandatory and Required findings, and make the failure message name the guideline and line. Weeks 5 to 7.
5. Run the full analysis nightly and at releaseSchedule the whole-project run with cross-file rules, send regressions to your tracker, and run the same job on every release tag with pinned versions. Weeks 7 to 10.
6. Archive evidence and review deviations each releaseStore the raw results, tool and ruleset versions, deviation register snapshot and compliance summary with the release artifacts, and review open deviations before sign-off. Weeks 10 to 13.

The compliance angle: ISO 26262, IEC 62304 and DO-178C

None of these standards names a specific tool, and none of them says "pass MISRA." What they ask for is a defined coding standard, evidence that you applied it, and confidence in the tools you used to check it.

ISO 26262 recommends using coding guidelines, and MISRA C is the usual choice in automotive. The standard also has a tool classification process: you assess how likely a tool error is to introduce or hide a defect, and how likely you'd catch it, and that gives a confidence level. A static analyzer can land above the lowest level depending on what else would catch a missed violation, and several vendors sell qualification kits to help. For DO-178C projects, tool qualification is covered separately in DO-330.

Medical device teams work under IEC 62304 and a quality system that expects tools used in the process to be fit for purpose and under configuration control. Your assessor or notified body decides how much evidence that takes, so ask early rather than after the pipeline is built.

Whatever the standard, the evidence bundle looks similar per release: commit SHA, analyzer version, ruleset file and its hash, raw results, the deviation register snapshot, and a guideline compliance summary. Authoritative sources: the MISRA consortium site for the guidelines and MISRA Compliance:2020, RTCA for DO-178C and DO-330, and the FDA medical devices pages for software expectations in the US. For practical delivery notes in regulated settings, browse the Stonetusker articles library.

Frequently asked questions

Related reading: Stonetusker articles library · Success stories · TuskerGauge, the free DevOps health assessment