What is static code analysis and what is the scope of it?

IMT AG strives for the best possible software quality and security, which is why it relies, among other things, on static code analysis and uses suitable static code analysis tools for this purpose.

These tools support IMT in a wide variety of projects. Especially in medical technology, they are a good supplement to meet the requirements of the IEC 62304, MDR, or FDA standards.

The term static code analysis typically describes the use of a tool to perform static tests. However, it also includes code reviews, for example.

1. What are static tests?

Software testing is divided into two categories, static testing and dynamic testing.

1. The static test is performed without executing the application. Static testing of source code is very common. Static testing includes not only analysis of source code, but also testing of object files, libraries, and executables (binaries). The term static test is often used implicitly with the static testing of source code. In the following chapters, the static code analysis is considered only in connection with the source code analysis. Strictly speaking, apart from the static analysis tools, a partial functionality of the compilers falls under the static tests. More in addition in chapter 3.3. The main purpose of static tests is the examination of the code on its conformity, security, and reliability.
2. Dynamic tests include all tests in which the application or parts of the application are executed in order to test the correct functionality. In order to detect errors, a (test) application must first be built.

2. Why use a static code analysis tool?

1. Compared to manual code reviews, tools can analyze the code automatically and reproducibly. This results in a time advantage of a tool compared to the manual examination.
2. Automation enables simple integration into the continuous integration process and thus automated generation of the analysis reports or automated detection of possible software defects. With the appropriate settings, even a merge request cannot be completed if defects are still detected by the static code analysis.
3. From the quality assurance view from the examples specified above much speaks for the use of a static code analysis Tool. One disadvantage could be the time needed to set up the tool correctly. Once it is up and running, experience has shown that changes to the configuration are rare.
4. Since typically only with the setting up of the static code analysis Tool much time must be invested, it recommends itself to set up the Tool as early as possible in the project.
   Static-code analysis is typically a part of the build process. The build process is executed before the (dynamic) test process since the application and test application must be built first. Static code analysis increases the probability of finding a bug during the build process, e.g. to save time.
5. Often static code analysis tools offer further features, which can be consulted for the code analysis. Among them are e.g.:
   
   • Code Metrics: Calculate code metrics to draw attention to critical areas.
   • “Dead code” recognition: Signals, if code is in the source code, which can never be executed, and/or is executed.
   • Design Analysis: Comparison of a software design and the implementation in the source code. Any deviations, such as cross-relationships, can be detected automatically.
   • Call Cycles: Detection of cyclic calls, which can potentially lead to memory overflows and thus to a complete failure of the software.

3. Are compilers also static analysis tools?

To answer this question, the following example will serve as an illustration:

The MISRA C++:202X coding standard is likely to be a bright spot in terms of up-to-dateness. At the time of writing, this standard was still in the review phase.

5. Static code analysis in the medical device environment

For software in medical technology, the IEC 62304 standard, the MDR, and the FDA must be taken into account in connection with static code analysis.

 

MDR

According to the Medical Device Directive MDD (93/42/EEC):

„For devices which incorporate software or which are medical software in themselves, the software must be validated according to the state of the art taking into account the principles of the development lifecycle, risk management, validation, and verification.”

In the event of litigation, an expert witness will likely confirm that the use of coding standards is “state of the art”.

 

FDA

The FDA document Software Validation Guidance states:

“The software design specification should include […] Development procedures and coding guidelines (or other programming procedures); […] Firms frequently adopt specific coding guidelines that establish quality policies and procedures related to the software coding process. Source code should be evaluated to verify its compliance with specified coding guidelines. Such guidelines should include coding conventions regarding clarity, style, complexity management, and commenting. Code comments should provide useful and descriptive information for a module, including expected inputs and outputs, variables referenced, expected data types, and operations to be performed. Source code should also be evaluated to verify its compliance with the corresponding detailed design specification. Modules ready for integration and test should have documentation of compliance with coding guidelines and any other applicable quality policies and procedures.”

Thus, the FDA does not explicitly require that coding standards be used or adhered to.

 

IEC 62304

Like the FDA, IEC 62304 does not explicitly require the use of or compliance with coding standards. However, the use of static code analysis can be used to support compliance.

The following chapters of ISO 62304 are relevant in the context of static code analysis:

 

5.1.12 Identification and avoidance of common software defects

The MANUFACTURER shall include or reference in the software development plan a procedure for:

1. identifying categories of defects that may be introduced based on the selected programming technology that are relevant to their SOFTWARE SYSTEM; and
   
2. documenting evidence that demonstrates that these defects do not contribute to unacceptable RISK.

 

5.5.2 Establish SOFTWARE UNIT VERIFICATION PROCESS

The MANUFACTURER shall establish strategies, methods, and procedures for verifying the SOFTWARE UNITS. Where VERIFICATION is done by testing, the test procedures shall be EVALUATED for adequacy. [Class B, C]

 

5.5.3 SOFTWARE UNIT Acceptance Criteria

The MANUFACTURER shall establish acceptance criteria for SOFTWARE UNITS prior to integration into larger SOFTWARE ITEMS as appropriate, and ensure that SOFTWARE UNITS meet acceptance criteria. [Class B, C]

NOTE Examples of acceptance criteria are:

• does the software code implement requirements including RISK CONTROL measures?
• is the software code free from contradiction with the interface design of the software unit?
• does the software code conform to programming procedures or coding standards?

 

5.5.4 Additional SOFTWARE UNIT acceptance criteria

When present in the design, the MANUFACTURER shall include additional acceptance criteria as appropriate for:

1. proper event sequence;
2. data and control flow;
3. planned resource allocation;
4. fault handling (error definition, isolation, and recovery);
5. initialisation of variables;
6. self-diagnostics;
7. memory management and memory overflows; and
8. boundary conditions.

[Class C]

 

To chapter 5.1.12:

A common set of rules as described in Chapter 3.4 can help to avoid frequent software errors and should therefore be mentioned in the software development plan.

 

To chapter 5.5.2

Here the static code analysis can be regarded as a method for the verification of software units.

 

To chapter 5.5.3:

In this chapter, it concerns mainly the last sentence concerning Coding standards. However, this sentence is only listed as an example.

 

To chapter 5.5.4:

By means of suitable Coding standards among other things the following enumerated points can be covered:

• (Planned) resource allocation
• Initialization of variables
• Memory management and memory overflows
• Boundary conditions
• Control flow

 

Conclusion

None of the regulations, authorities, or standards mentioned explicitly require the use of coding guidelines. However, their use could be considered as state of the art, which requires their use. A list of suitable coding guidelines is not provided.

The company IMT AG relies on regulations like:

• MISRA (Motor Industry Software Reliability Association)
• AUTOSAR (AUTomotive Open System ARchitecture)
• SEI CERT (Software Engineering Institut – Computer Emergency Response Team)

The use of a static code analysis with the support of a static code analysis tool makes sense for all software projects and should be used from the beginning if possible. A software manufacturer in the medical environment must use a coding guideline from a “state of the art” perspective. A static code analysis tool can automatically test the code against a set of rules (coding guidelines).

These are the top IMT best practices for static code analysis:

• If SCA is used, then also turn on all compiler warnings.
• Set up the SCA tool as early as possible in the project and integrate it into the CI/CD pipeline.
• In the medical area (ISO 62304 standard, MDR, FDA) the use of coding guidelines is required, which is why we strongly recommend static code analysis tools for automated static testing (including the coding guidelines). Suitable rule sets are
  • MISRA (Motor Industry Software Reliability Association),
  • AUTOSAR (AUTomotive Open System ARchitecture) and
  • SEI CERT (Software Engineering Institute – Computer Emergency Response Team).