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.
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.
Use these steps to help software developers write secure 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.
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.
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.
The entire application is scanned regularly (for example in the nightly build).