SURESOFT Verification Suite

Code Verification for Mission-Critical Software

The Suresofttech (SURESOFTTECH) verification suite supports code verification for mission-critical software in three stages: before the code runs (STATIC), while tests are designed and executed (CT), and by confirming how much of the code those tests actually executed (COVER).

3
Verification Products

STATIC · CT · COVER

1,200+
Static analysis inspection patterns

Based on STATIC Enterprise.

up to 10
Measurable code coverage types
Based on COVER Enterprise

Standalone supports up to 7.

6
Application domains

automotive · aerospace · defense · railway · nuclear · medical

Before the code runs,while the tests run, and from the results

Each product verifies a different point in the development flow

1

Implementation and coding

STATICStatic analysis · no execution

Detects coding rule violations and runtime errors without running the code

OUTPUTS

Defect list · Rule compliance rate · Metrics

2

Unit and integration testing

CTDynamic testing · design and execution

Designs and executes unit and integration tests; confirms statement, branch, MC/DC

OUTPUTS

Test results · Traceability · Coverage

3

System and target testing

COVERDynamic analysis · measured from results

Measures how much of the code the executed tests actually reached

OUTPUTS

Coverage indicators · Unexecuted code · Reports

CI All three run automatically in CIEvery code change is verified against the same criteria and the results accumulate

Why code verification is needed

The build passed and testing is done is not a verification result.

A successful compile does not mean there will be no defects at runtime

memory leaks, NULL dereferences, and array-bound overruns pass compilation and survive into execution.

A “testing complete” report without numbers behind it

if you do not know which code actually ran, defects in the branches and conditions your tests never reached simply remain.

Standards ask for records, not just activities

safety and regulated projects must leave behind, in reviewable form, what was verified and against which criteria.

The three products across the development flow

STATIC works before execution, CT designs and executes the tests, and COVER verifies from the test results.

Aspect STATIC CT COVER
Verification method Static analysis (no code execution) Dynamic testing (test design and execution) Dynamic analysis (measurement of execution results)
Question it answers Does this code contain rule violations and latent defects? Does this code behave as intended? How far into the code did the tests reach?
Primary stage Coding, commit, build Unit and integration testing From unit testing through system and target testing
Representative output Defect list, rule compliance rate, quality metrics Test results, requirements traceability, coverage Coverage indicators, unexecuted code, measurement reports

The products at a glance

Source Code Static Analysis

A static analysis tool that detects coding rule violations, runtime errors, and potential security vulnerabilities without executing the source code.

What it delivers

  • Runtime error detection without execution

    more than 1,200 inspection patterns and more than 30 kinds of semantic analysis find memory, arithmetic, and array-bound errors before the code is ever run.

  • Automatic checking against domain rule sets

    automatically checks coding rules such as MISRA, AUTOSAR C++14, and CERT, CWE-based security weaknesses, and items from DAPA, HKMC, and Ministry of the Interior and Safety guidelines.

  • Management that does not stop at detection

    tracks defect status and assignees, and manages quality trends with the rule compliance rate (RCR) and defect density.

Feature summary
coding rule inspection · runtime error detection · software quality metrics · defect management and objective tracking · AI-assisted remediation (Smart Suggestion, Agent Chat) · CI and configuration management integration
Editions
Enterpriseweb server-based central management; C/C++, C#, Java, Kotlin, Python StandaloneVS Code-based IDE; C/C++
Learn more about STATIC →
Example of the STATIC Enterprise project list screen. For each project the language, manager, remaining/suppressed/new/closed defect counts, and latest analysis time are displayed, so the code quality status of multiple projects can be compared at a glance.
Project static analysis statuscompare the analysis status and defect indicators of multiple projects on one screen

Dynamic Code Verification

A test automation solution for unit, integration, and code-based testing of mission-critical C/C++ software. It connects test environment setup, test design and generation, execution, code coverage analysis, reporting, and traceability management into a single flow.

What it delivers

  • Unit and integration verification in one flow

    manages test conditions and data, designs and executes tests at the function, module, and interface level, and confirms them with statement, branch, and MC/DC coverage.

  • Less repetitive work in test design

    ALIRA AI inside the product and DVERA, the integration solution for AI coding agents, assist with test design, generation, and error analysis. Generated tests are verified against actual execution results and code coverage.

  • Verification that leaves evidence behind

    links requirements, tests, execution results, and coverage for use as review reports and traceability records.

Feature summary
unit and integration test design and execution · reuse of existing Google Test assets · statement/branch/MC/DC coverage with control flow views · ALIRA AI · DVERA · CI-based repeated verification · team testing · ALM (Polarion, codebeamer) and V-SPICE integration
Tool certification
CT holds TÜV SÜD tool certification for ISO 26262, IEC 62279/EN 50716, IEC 60880, IEC 62304, and IEC 61508. The certification applies to a specific CT version and the functional scope defined in the Certification Report.
Learn more about CT →
Example of CT code coverage results — C/C++ code, statement, branch, and MC/DC coverage per function, and a control flow graph on one screen. The figures shown are examples.
Code coverage and control flowreview under-covered code together with its execution paths

Test Coverage Measurement

A dynamic analysis tool that analyzes test execution results as code coverage to confirm the sufficiency of software testing.

What it delivers

  • Multiple coverage types from a single test run

    Enterprise measures up to 10 coverage indicators and Standalone up to 7 from the results of a single test execution.

  • Measurement without changing your test procedure

    after the initial integration setup, you continue to use your existing compilers, IDEs, and test methods, and application source code is not modified manually.

  • Measurement all the way to embedded targets

    a proprietary probe insertion method (Korean Patent No. 10-1667262) keeps the probe code small, so measurement is possible even on targets with little memory headroom. Execution overhead is around 10%.

    Actual overhead varies with the language, target performance, the coverage types measured, and the instrumentation scope.
Feature summary
function, statement, line, branch, and MC/DC coverage measurement · per-line execution display and MC/DC truth tables · changed-function and changed-line coverage (EE) · organization-level aggregation and reporting (EE) · embedded target measurement (SE) · built-in measurement criteria per standard and guideline · Open API and CI integration
Editions
Enterpriseagent + server + web; C/C++, C#, Java Standalonelocal PC installation; C/C++, C#
Learn more about COVER →
Example of the COVER Enterprise module detail screen. A per-file coverage tree, a statement coverage summary, a bar chart of the 10 coverage types, and a test priority list are shown together. The figures on screen are example data.
Module coverage statuscoverage summary, coverage types, and test priorities on one screen

Which product do you need?

What you need right now Where to start
Check and evidence compliance with coding rules (MISRA, CERT, and others)STATIC
Filter out memory, arithmetic, and boundary errors that are hard to reproduce in testingSTATIC
Manage code quality trends and defect handling across the organizationSTATIC
Design and execute unit and integration tests and produce test recordsCT
Maintain traceability linking requirements to tests and execution resultsCT
Generate and run tests inside an AI coding agent workflowCT
Measure how much code your existing tests actually executeCOVER
Measure coverage on a real target boardCOVER
Consolidate coverage scattered across teams and servers into one reportCOVER
Build verification evidence for the highest grades such as ASIL D or Software Level ASTATICCTCOVER

Using all three together

Clear the rule violations first, confirm behavior through testing, then confirm sufficiency with coverage - one connected body of verification evidence.

  1. Coding stage

    STATIC detects coding rule violations and runtime errors at commit and build time, assigns defects to owners, and tracks their handling status.

  2. Unit and integration testing stage

    CT designs and executes requirements-based and structure-based tests, leaving statement, branch, and MC/DC coverage together with requirements traceability.

  3. Sufficiency confirmation stage

    COVER measures coverage from test execution results including system testing and real-target testing, and uses unexecuted code as the basis for deciding what testing to add.

  4. Repeated verification

    all three products can run automatically in a CI environment, so every code change is verified against the same criteria and the results accumulate.

The integrated verification flow

  1. 1Write code
  2. 2Test and integrate
  3. 3Confirm sufficiency
  4. 4Accumulate evidence
  1. 1Write code

    STATIC

    Detects coding rule violations and runtime errors at commit and build time, then assigns them to owners for tracking.

  2. 2Test and integrate

    CT

    Designs and executes requirements-based and structure-based tests, recording coverage and requirements traceability.

  3. 3Confirm sufficiency

    COVER

    Measures coverage from system and target testing results, then uses unexecuted code to scope further testing.

  4. 4Accumulate evidence

    ALL THREE

    Links defect, test, and coverage records into one body of verification evidence for reports and traceability.

Repeated in CI on every code change

Industries and standards

Each product supports the verification activities required in safety and regulated projects in its own way.

Domain Representative standard STATIC CT COVER
Automotive ISO 26262 Coding rule inspection and static analysis results used as verification evidence Unit and integration testing, coverage, traceability (within TÜV SÜD certification scope) Built-in measurement criteria for ASIL A–D
Aerospace DO-178C / DO-330 Static analysis results used as verification evidence Supports the verification activities (not within the TÜV SÜD certification scope; tool qualification is judged per project) Built-in measurement criteria for Software Level A–D and TQL-1–5
Defense DAPA weapon system software guidelines Rule sets based on the reliability evaluation guidelines, 6 function metrics Unit and integration testing with test result management Built-in statement, branch, and MC/DC criteria
Railway IEC 62279 / EN 50128 · EN 50716 Static analysis results used as verification evidence Unit and integration testing, coverage, traceability (within TÜV SÜD certification scope) Built-in measurement criteria for SIL 0–4
Nuclear IEC 60880 Static analysis results used as verification evidence Unit and integration testing, result and report management (within TÜV SÜD certification scope) Built-in statement, branch, and MC/DC criteria
Medical devices IEC 62304 Static analysis results used as verification evidence Test execution, result and traceability records (within TÜV SÜD certification scope) Built-in measurement criteria for Class A–C
Functional safety (general) IEC 61508 Coding rule inspection and static analysis results used as verification evidence Unit and integration testing, coverage, verification records (within TÜV SÜD certification scope) Built-in measurement criteria for SIL 1–4

Tool certification and tool qualification are different things.

CT holds TÜV SÜD tool certification for the standards marked above, and the certification applies to a specific product version and the functional scope defined in the Certification Report. DO-178C and DO-330 are not within CT's TÜV SÜD certification scope; for aerospace projects, tool qualification is judged per project based on the intended use and how the verification evidence is used. STATIC and COVER provide tool qualification materials for use in certification reviews; the materials actually provided and the applicable product versions and standard scope must be confirmed per project.

AI-assisted verification

AI is used to reduce repetitive work, and its output is verified against actual execution results and code coverage.

Tests and judgments produced by AI are not verification evidence on their own. The test intent and expected results are reviewed first, and confirmation still comes from actual execution results and code coverage.

STATIC Agent Chat

answers questions about tool usage, defect causes, and remediation guidance based on the STATIC guide documentation.

STATIC Smart Suggestion

finds and recommends past suppression history similar to the current defect, and lets you compare the original code with the recommendation in a diff view before accepting it.

CT ALIRA AI

assists with the design and generation of requirements-based and structure-based tests, and with error analysis, inside CT.

CT DVERA

connects AI coding agents such as Claude Code, Codex CLI, Cursor, and GitHub Copilot so they can use CT's analysis, execution, and coverage capabilities directly from their working context.

Customer cases

Automotive

Custom coding rules to prevent recurring errors

Problem
an engine design project (C) needed custom rules to prevent errors that had actually occurred from recurring
Application
custom coding rules were developed and applied with STATIC, and a rule verification step was added to the development process
Result
used in the verification activities for ISO 26262 compliance

Defense embedded

Meeting reliability test criteria

Problem
100% statement coverage and a software reliability test had to be achieved
Application
coverage of requirements-based testing was measured with COVER, gaps were filled with structure-based testing in CT, and each set of results was uploaded to VPES
Result
a procedure was established to combine requirements-based, structure-based, and target test results into a reliability test report

Financial IT

Coverage as the gate for production release

Problem
changed code reached production without any confirmation of test sufficiency, creating incident risk
Application
COVER real-time monitoring was connected to the release approval check, and requests below 80% function coverage were rejected
Result
a quality gate that requires additional testing before production release

Frequently asked questions

Do we have to adopt all three products together?

No. Each product can be used independently. Because their verification purposes differ, however, projects that require coding rule compliance (STATIC), unit and integration testing (CT), and test sufficiency confirmation (COVER) get a single connected body of evidence when the products are used together.

Which product should we adopt first?

The first product to adopt depends on which verification evidence your project lacks most. Start with STATIC if there is no code quality baseline, with CT if unit test records are required, and with COVER if you must confirm the sufficiency of testing you already perform. See Which Product Do You Need? for the detailed criteria.

Which languages are supported?

STATIC Enterprise supports C/C++, C#, Java, Kotlin, and Python, and STATIC Standalone supports C/C++. CT targets C/C++. COVER Enterprise supports C/C++, C#, and Java, and COVER Standalone supports C/C++ and C#. Language versions and development environments are listed in the supported languages document.

Can they be integrated into a CI/CD pipeline?

All three products can run automatically in a CI environment. STATIC performs static analysis automatically during the build, CT repeats regression tests and coverage analysis through the CLI, a Jenkins plugin, or Docker, and COVER aggregates results through its Open API and CI integration. See each product page for the integration details.

Can they be used in an air-gapped (network-separated) environment?

Yes. For STATIC and COVER, the Enterprise editions run on servers and analysis or measurement agents inside your internal network, and the Standalone editions are installed on a local PC. Conditions such as AI feature availability and licensing method should be confirmed during the consultation.

Can they be applied to embedded target environments?

Yes. STATIC supports embedded toolchains such as IAR, Keil, TASKING, Renesas, TI, and Microchip; CT executes tests on real targets over Ethernet, Serial, or JTAG; and COVER Standalone measures coverage even on resource-constrained targets.

Do you provide materials for certification?

CT holds TÜV SÜD tool certification for ISO 26262, IEC 62279/EN 50716, IEC 60880, IEC 62304, and IEC 61508, and STATIC and COVER provide tool qualification materials. The scope actually provided and the applicable product versions must be confirmed per project.

Next steps

Find the verification scope and product configuration that fit your project environment.

Product One-line definition Link
STATIC A static analysis tool that detects coding rule violations and runtime errors without execution Learn more →
CT A unit, integration, and code-based test automation solution for mission-critical C/C++ Learn more →
COVER A dynamic analysis tool that analyzes test execution results as code coverage Learn more →