Application SecurityStatic Application Security Testing

Security from the first line of code

Use the white box approach of Static Application Security Testing (SAST) to protect your applications from the first line of source code.

With this static analysis, the source code can be viewed during the analysis and the application does not have to be running. This makes SAST particularly suitable at the beginning of the software development lifecycle and should be integrated into your development pipelines at an early stage.

Contact

CEOThomas Jähnig+49 351 4400 8124+49 157 7465 3532tjaehnig (at) proficom.de

Send mail

Mit der statischen Quellcode-Analyse wird der Code auf potentielle Schwachstellen untersucht

What is ist Static Application Security Testing?

The static security analysis of an application examines the source code for potential security vulnerabilities. There are various methods of analysis. Most tools use a set of rules in the background, which defines when a line of source code or line of code is defined a block of source code is considered unsafe and when not. Other tools simulate the application at runtime using the source code, for example to identify buffer overflow problems.

Thanks to SAST's white box approach, the entire source code can be viewed during the analysis, which enables dependencies within the application to be recognized and also analyzed. This makes it possible to identify so-called data flow issues, such as SQL injections or cross-site scripting.

What you should know

Advantages

Early detection of potential security vulnerabilities saves costs
No executable source code required during the analysis
White box approach: 100 percent of the application is scanned (in contrast to the black box approach or Dynamic Application Security Testing (DAST)
Simple integration options into existing development environments

Disadvantages

Tools usually have a high false positive rate. There will be a lot of potential security vulnerabilities, only a fraction of which really need to be fixed in the end.
Security weaknesses that are directly related to the runtime or the runtime environment are not recognized by SAST alone. Dynamic analysis (DAST) can help here.

Vor- und Nachteile der statischen Quellcode-Analyse

Best Practices

Tried and tested procedure

Use these steps to help software developers write secure code.

Code

The developer writes source code in the IDE and is supported by IDE plugins, which analyze the source code - already while it is being written - and provide information on secure code (e.g. Fortify Security Assistant or Veracode GreenLight). However, these plugins usually only analyze the file that is currently open and not the entire project, which means that a full scan of the entire project is necessary.

Push & Scan

After the developer pushes into the repository, a full scan of the source code is triggered. During this scan, the tools examine the entire project from different angles in order to deliver the most accurate result possible. If too many new security vulnerabilities occur during this scan, the push is discarded and the developer receives the results to remedy the vulnerabilities.

Check

The developer can view the results in his IDE with the help of plugins and adapt the source code if necessary. The plugins provide corresponding information on how the weak points are to be assessed and remedied.