Static analysis tools for embedded C and C++ (2026)

1. ~70%

   For more than a decade, about 70% of the CVEs Microsoft assigned each year were memory safety defects. Most of that code was C and C++.

   Source: Microsoft Security Response Center, 2019

2. 70% of 912

   In a sample of 912 high and critical Chrome security bugs since 2015, about 70% were memory safety bugs in C and C++. About half of those are use-after-free.

   Source: The Chromium Projects, memory safety

3. 76% → 24%

   Memory safety bugs fell from 76% to 24% of Android vulnerabilities between 2019 and 2024 (the 2024 figure is a full-year projection). New code moved to memory-safe languages; the old C and C++ stayed.

   Source: Google Online Security Blog, September 2024

4. 7 of 25

   Seven of the 25 entries in the 2025 CWE Top 25 are memory and pointer defects. C and C++ SAST tools look for all seven. They are out-of-bounds write (#5), use after free (#7), out-of-bounds read (#8) and NULL pointer dereference (#13). The other three are buffer overflows: classic (#11), stack-based (#14) and heap-based (#16).

   Source: MITRE, 2025 CWE Top 25

5. 143 + 16

   The first edition of MISRA C:2012 has 143 rules and 16 directives. Amendments 1 and 2 raise that to 158 rules and 17 directives. Tools check rules and some directives in full or in part. The rest needs manual review.

   Source: Perforce, MISRA C and MISRA C++ guidelines

6. 10 years of SATE

   In ten years of NIST Static Analysis Tool Exposition data, tools looked for different weaknesses and warning volumes varied widely. They overlapped much only in known classes such as buffer errors.

   Source: NIST SP 500-326, SATE V report

7. 7 agencies

   In December 2023, CISA, the NSA, the FBI and agencies from Australia, Canada, New Zealand and the UK asked vendors to publish memory-safe roadmaps. They called memory safety bugs the most common type of disclosed vulnerability.

   Source: CISA, The Case for Memory Safe Roadmaps

The Microsoft, Chrome and Android figures show how much memory safety matters in large C and C++ codebases. Agencies now expect a plan for it. The NIST data shows that analyzers disagree on what they look for. None of these figures measure how well any analyzer works.

The following rules were applied:

1. A capability is marked as supported only when the vendor or project documentation states it.
2. Coding-standard support is described at family level. Exact rule coverage, standard edition and licensing can differ by product version or module.
3. We give no scores for accuracy, false-positive rate or speed. Those need the same codebase, configuration, hardware and acceptance criteria.
4. "Best fit" describes product positioning and documented capabilities. It is not a universal ranking.
5. Pricing is excluded because most enterprise vendors use project-specific quotes and package features differently.

1. SAST and static analysis: the same thing?

   SAST stands for static application security testing. Security teams use it for analysis of source or binary code, without running it, to find exploitable weaknesses. Examples are buffer overflows, injection paths and unsafe memory handling. In embedded work, static analysis is wider. It also covers coding standards, runtime-error proof and maintainability.

   Most products here are sold as SAST tools. A platform built for web stacks may parse C and C++ yet fail to model a cross-compiler, a real-time operating system (RTOS) or generated code. For embedded C and C++, the build and environment model usually decides, more than the checker count.

2. Defect-oriented analysis

   Most static analyzers are designed to find likely defects and vulnerabilities. They combine syntax and semantic checks with control-flow, data-flow, taint, path and interprocedural analysis. The result is a set of findings for human review.

   This model suits continuous use on a large codebase. It does not prove that an error class is absent. A clean run means the configured analyzer reported nothing. It does not mean the program is correct.

3. Sound or proof-oriented analysis

   Sound analyzers intentionally over-approximate possible program behavior. When the analysis proves a property under its stated assumptions, the result can establish the absence of a defined class of errors. The cost is stricter modeling, more configuration and potential alarms caused by behavior that is possible in the model but impossible in the real system.

   Polyspace Code Prover and Astrée are the clearest proof-oriented products in this comparison. They should not be evaluated by the same criteria as a fast pull-request scanner.

4. Coding-standard compliance

   For MISRA, AUTOSAR or CERT support, check:

   • The exact edition required by the project
   • Which rules are enforced automatically
   • Which guidelines are not statically decidable
   • How deviations are documented and approved
   • Whether compliance reports match the required audit format
   • Whether a qualification kit covers the selected tool version and configuration

   A tool can find many MISRA violations and still lack a compliance process. A compliance product can enforce rules well while another analyzer finds more logic or security defects.

5. Compiler and environment modeling

   Embedded code rarely looks like portable desktop C++. Real projects contain compiler intrinsics, target-specific integer models, generated code, conditional compilation, RTOS APIs, custom allocators, hardware registers and inline assembly.

   If the analyzer cannot rebuild your real build, the rest of the feature list matters much less. Test compiler and environment modeling first, then compare dashboards.

• Whether the analyzer reproduces the real preprocessing and build configuration
• Whether it understands the target's integer widths and compiler extensions
• Whether findings cross function, file and module boundaries
• Whether generated code and third-party code can be handled separately
• Whether a developer can understand and reproduce the reported path
• Whether existing warnings can be baselined without hiding new risk
• Whether suppressions and deviations remain traceable
• Whether the central scan and pull-request scan use comparable rules
• Whether reports satisfy an assessor, customer or internal security process
• Whether custom models can describe project-specific APIs and state transitions

Whether the analyzer reproduces the real preprocessing and build configuration Whether it understands the target's integer widths and compiler extensions Whether findings cross function, file and module boundaries Whether generated code and third-party code can be handled separately Whether a developer can understand and reproduce the reported path Whether existing warnings can be baselined without hiding new risk Whether suppressions and deviations remain traceable Whether the central scan and pull-request scan use comparable rules Whether reports satisfy an assessor, customer or internal security process Whether custom models can describe project-specific APIs and state transitions Put real technical scenarios in your request for proposal. A spreadsheet of vendor claims will not show these differences.

1. 01

   Select representative code

   Pick a component that contains what most often breaks analysis. That means target headers and intrinsics, build variants, generated source, RTOS primitives and custom memory management. Add a few known defects and one recent change that crossed several modules.

   Do not use a small demo project. It rewards quick setup and tells you little about production fit.

2. 02

   Define the expected outcome

   Write down what the pilot tests. Typical goals are defect discovery, MISRA or CERT enforcement, proof of runtime-error absence, feedback on changed code, governance across branches, third-party code and custom detectors.

   One pilot can cover several goals, but each goal needs separate acceptance criteria.

3. 03

   Measure useful signal

   Do not rank tools by warning count. More warnings can mean better detection, duplicate rules, bad configuration or noise. Count confirmed high-impact findings and new actionable ones. Count false or irrelevant ones too. Time how long each report takes to understand, and check that findings stay stable after small code changes.

4. 04

   Test the full workflow

   Run both a clean project analysis and an incremental change. Connect the tool to the intended CI system and IDE. Test baselining, suppression, assignment, quality gates, exports and access controls. If the code cannot leave the organization, verify what data is processed or stored outside the selected environment.

5. 05

   Check the evidence

   For regulated projects, ask which documents the proposed license includes. Look for qualification material, a rule-coverage matrix for your standard edition and a guideline compliance summary. Also check deviation records, versioned configuration, audit exports and the long-term support policy.

1. 01Compiler warnings for immediate language and build diagnostics
2. 02clang-tidy or another linter for local coding practices
3. 03Cppcheck or Clang Static Analyzer for an additional open-source defect layer
4. 04A commercial SAST or compliance analyzer for centralized control, standards and cross-module findings
5. 05A proof-oriented analyzer for selected high-criticality components
6. 06Unit, integration, hardware-in-the-loop and system testing
7. 07Fuzzing and security testing for behavior that source analysis cannot establish
8. 08Runtime monitoring for failures that depend on the deployed environment