Static code analysis tools for complex systems

Choose an analyzer based on how it reasons about code, adapts to project-specific rules and fits into the rest of your verification workflow.

Visao is the static analysis component inside Midair, built for code where generic checks are not enough.

What matters when choosing a static analysis tool

Analysis depth

Does the analyzer only match known patterns, or can it reason about execution paths and program state?

Project-specific rules

Can the tool express constraints that matter to your own system rather than only predefined generic checks?

Workflow integration

Can findings be used in CI/CD and carried into later testing?

Evidence after the finding

Does the result end as a static report, or can it stay connected to the test run and runtime behavior that follows?

Some analyzers provide predefined standards mappings. Visao currently focuses on project-specific rules rather than presenting a public out-of-the-box standards matrix.

Visao

What makes Visao different

Path-aware analysis

Investigate issues that depend on how execution reaches a particular state.

Project-specific checks

Add rules for failure conditions and constraints that are specific to the codebase.

Concrete findings

Surface issues such as unsafe memory use, integer overflow and violations of project-specific rules.

Connected verification

Carry a finding into Midair when it needs to be checked against a test run or runtime evidence.

Visao in Midair

1

Analyze

Visao

Visao examines source code before execution.

2

Investigate

Visao

Review the exact source, execution path and rule behind a finding.

3

Validate when needed

TS Factory

Carry relevant findings into a TS Factory test run.

4

Keep the evidence connected

Delta · Midair

Compare the static finding with Delta runtime evidence inside Midair.

Use cases

•

Embedded software and firmware

Code that eventually runs on hardware with limited runtime observability.

•

Network and system software

Low-level software whose behavior depends on system context.

•

Security-sensitive code

Software where unsafe behavior should be investigated before runtime.

•

Complex C and C++ codebases

Large source trees where a defect can hide on a rarely taken path.

•

Projects with domain-specific rules

Systems where generic analyzers cannot express every failure condition that matters.

Comparing static analysis tools?

Language support, standards coverage, analysis depth and workflow integration vary significantly between tools. For a broader comparison of commercial and open-source analyzers for embedded C and C++, see our 2026 research. It compares eleven tools, including Coverity, Klocwork, Polyspace, CodeSonar, Parasoft C/C++test, PVS-Studio and Cppcheck.

SAST, MISRA C and CERT C

Three terms that come up in almost every tool evaluation for C and C++.

SAST

Static application security testing analyzes source or binary code without running it. It looks for exploitable weaknesses such as buffer overflows, unsafe memory handling and tainted data paths. In embedded work, SAST is one part of static code analysis, which also covers coding standards and maintainability.

MISRA C

A set of coding guidelines for C in safety-related systems. MISRA C:2012 defines 143 rules that an analyzer can check in source code, and 16 directives about process and design that no tool can decide alone. MISRA compliance is not the same as functional-safety certification.

CERT C

The SEI CERT C Coding Standard: rules and recommendations that remove undefined behavior and security-relevant defects in C. CERT C is led by security, MISRA C by safety. Most commercial analyzers map their checks to both.

Start your pilot

Start with your own codebase and see how Visao handles the rules and failure conditions that matter to your system.