Static application security testing (SAST) is used to secure software by reviewing its source code to identify security vulnerabilities. Although the process of checking programs by reading their code (modernly known as static program analysis) has existed as long as computers have existed, the technique spread to security in the late 90s and the first public discussion of SQL injection in 1998 when web applications integrated new technologies like JavaScript and Flash.
Unlike dynamic application security testing (DAST) tools for black-box testing of application functionality, SAST tools focus on the code content of the application, white-box testing. A SAST tool scans the source code of applications and their components to identify potential security vulnerabilities in their software and architecture. Static analysis tools can detect an estimated 50% of existing security vulnerabilities in tested applications. [1]
In the software development life cycle (SDLC), SAST is performed early in the development process and at code level, and also when all pieces of code and components are put together in a consistent testing environment. SAST is also used for software quality assurance, [2] even if the many resulting false positives impede its adoption by developers. [3]
SAST tools are integrated into the development process to help development teams as they are primarily focusing on developing and delivering software respecting requested specifications. [4] SAST tools, like other security tools, focus on reducing the risk of downtime of applications or that private information stored in applications is not compromised.
For the year of 2018, the Privacy Rights Clearinghouse database [5] shows that more than 612 million records in the United States have been compromised by hacking.
Application security tests conducted before their release include static application security testing (SAST), dynamic application security testing (DAST), and interactive application security testing (IAST), which is a combination of the two. [6]
Static analysis tools examine the text of a program syntactically. They look for a fixed set of patterns or rules in the source code. Theoretically, they can also examine a compiled form of the software. This technique relies on instrumentation of the code to do the mapping between compiled components and source code components to identify issues. Static analysis can be done manually as a code review or auditing of the code for different purposes, including security, but it is time-consuming. [7]
The precision of SAST tools is determined by their scope of analysis and the specific techniques used to identify vulnerabilities. Different levels of analysis include the following:
The scope of the analysis determines its accuracy and capacity to detect vulnerabilities using contextual information. [8] SAST tools, unlike DAST tools, give developers real-time feedback, and help them secure flaws before they move the code to the next level.
At a function level, a common technique is the construction of an Abstract syntax tree to control the flow of data within the function. [9]
Since the late 90s, the need to adapt to business challenges has transformed software development with componentization [10] enforced by processes and organization of development teams. [11] Following the flow of data between all the components of an application or group of applications allows validation of required calls to dedicated procedures for sanitization and that proper actions are taken to taint data in specific pieces of code. [12] [13]
The rise of web applications entailed testing them: Verizon Data Breach reported in 2016 that 40% of all data breaches use web application vulnerabilities. [14] Both external security validations and a focus on internal threats have risen. The Clearswift Insider Threat Index (CITI) has reported that 92% of their respondents in a 2015 survey said they had experienced IT or security incidents in the previous 12 months and that 74% of these breaches were originated by insiders. [15] [16] Lee Hadlington categorized internal threats in 3 categories: malicious, accidental, and unintentional. Mobile applications' explosive growth implies securing applications earlier in the development process to reduce malicious code development. [17]
The earlier a vulnerability is fixed in the SDLC, the cheaper it is to fix. Costs to fix in development are 10 times lower than in testing, and 100 times lower than in production. [18] SAST tools run automatically, either at the code level or application-level and do not require interaction. When integrated into a CI/CD context, SAST tools can be used to automatically stop the integration process if critical vulnerabilities are identified. [19]
Another advantage over other types of testing is that SAST tools scan the entire source code, while dynamic application security testing tools cover its execution, possibly missing part of the application [6] or unsecured configuration in configuration files.
SAST tools can offer extended functionalities such as quality and architectural testing. There is a direct correlation between software quality and security. Bad quality software is also poorly secured software. [20]
Even though developers are positive about the usage of SAST tools, there are different challenges to their adoption. [4] As an example, research shows that despite the long output generated by these tools, they may lack usability. [21]
With Agile Processes in software development, early integration of SAST generates many bugs, as developers using this framework focus first on features and delivery. [22]
Scanning many lines of code with SAST tools may result in hundreds or thousands of vulnerability warnings for a single application. It can generate many false positives, increasing investigation time and reducing trust in such tools. This is particularly the case when the context of the vulnerability cannot be caught by the tool. [3]