Arrange a initial consultation!

Simply make an appointment online for a non-binding and free initial consultation with one of our employees.

Arrange Call

Static Code Analysis

Static Code Analysis, also known as Source Code Analysis, is usually performed within the framework of a Code verification and takes place in the implementation phase of a Security Development Lifecycle (SDL). Static code analysis usually refers to the use of tools such as for static code analysis, which tries to identify possible vulnerabilities in the "static" not running source code. This method is a white-box test.

A basic distinction is made between dynamic and static test procedures. With dynamic The functionality of the test procedure is tested by executing code. This category includes for example unit and function tests. In contrast, the category of static test procedures includes for example, manual reviews and static code analysis. Static means that the program is not executed, but the check only takes place on the basis of the source text.

In the development environment


Ideally, such tools will automatically find security flaws with a high degree of confidence that what's found is actually a mistake. However, this exceeds the state of the art for many types of security vulnerabilities in the application. Therefore, such tools often serve as tools for an analyst to help them find security-related code parts so that they can identify errors more efficiently than a tool that simply finds errors automatically. Some tools begin to integrate into the Integrated Development Environment (IDE). For the types of problems, which can be detected during the software development phase itself, this is a powerful phase within the development lifecycle to deploy such tools, as they are the most developer gives immediate feedback on problems he encounters during code development himself in the code that I could bring to the table. This immediate feedback is very useful if you want to identify vulnerabilities much later. in the development cycle.

Techniques


There are several techniques for analyzing static source code for potential vulnerabilities that might be combined into a solution. These techniques are often derived from compiler technologies.

Data Flow Analysis

Data flow analysis is used to collect runtime (dynamic) information about data in the software while it is in a static state. There are three common terms used in data flow analysis: Basic construction (the code), control flow analysis (the data flow), and control flow path (the path the data takes): Data flow analysis considers the state of a variable along a path. First, a graph of the program (or a function) is created, which contains all paths. Then it is recorded which actions are carried out along each path with this variable. A distinction can be made between four different actions. The first patterns do not necessarily have to be errors, but can also have been intentional.

Control Flow Diagram

In the control flow analysis, the program flow is analyzed. For example code fragments that can never be reached during program execution. Often already compilers detect such errors (for example the Java compiler javac). Such code does not necessarily lead to mistakes. However, this is very likely to be the case, that the programmer of this fragment had intended a different program flow.

Taint Analysis

Taint analysis attempts to identify variables that are associated with user-defined inputs. "polluted" and pursues them to possible vulnerable functions, also known as the "sink." can be designated. If the variable is passed to a sink without being "cleaned" first it is identified as a vulnerability.

Syntax Analysis

In syntax analysis, often also called lexical analysis, the source code is checked against syntax and grammar rules. Tools that perform syntax analysis are compilers and interpreters. The syntax analysis takes place during each compiler run. If an error is detected, an error message is generated and the compiling process is aborted. The style analysis uses sets of rules that affect the programming style. On the one hand, these can be, for example, company-internal coding style guides. This keeps the code uniform within a company and makes it easier to read and maintain. On the other hand, they can also be programming language-specific guidelines. The aim of these guidelines is to avoid unsafe programming constructs. In many safety-critical areas of software in embedded systems, compliance with such standards is even mandatory.

Interested? Convinced? Interested?

Request a sample report or our service portfolio today. We will be happy to assist you!

We have received your message. We will get back to you shortly. An error has occurred. Please try again.