What benefits does SAST have? What's the difference between SAST and DAST? What's IAST? What do all these words mean?! Let's talk about this and more in the overview of the main types of Application Security Testing (AST).
Before we start deciphering these terms, let's figure out why we need security testing at all. In modern world, software integrates into automation processes almost everywhere, the number of code lines in applications is increasing. As a result, the number of possible vulnerabilities and errors is increasing as well. This creates the need for effective checking and testing of the source code.
According to the Positive Technologies research conducted in 2019, 82% of all detected vulnerabilities are caused by mistakes made at the code writing stage. The experts conclude that on average, every second system has a security defect with a high level of risk. One of the main reasons of this problem is the lack of code checks for vulnerabilities at the writing stage. Also, one of the not-so-obvious factors is that developers don't pay much attention to security. They focus more on the application's functionality.
Nevertheless, the increase in the number of vulnerabilities and the possibility that attackers would exploit these vulnerabilities forces the application security market to develop rapidly. This fact is well demonstrated by the results of a study by Grand View Research:
Figure 1. U.S. application security market by end-use, 2014-2025 (USD million).
There is an opinion that not all vulnerabilities are potentially dangerous. Some of them may exist in source code for years and never lead to anything bad. To set priorities for fixing vulnerabilities, developers rely on the CVSS (Common Vulnerability Scoring System) standard, but:
Yes, we can say that the quality of code testing has been increasing over the years. This is because a variety of tools designed for testing code has been developed as well. Old vulnerabilities are fixed, but new ones appear. Besides, attackers also develop the tools and methods for detecting incorrect code and vulnerabilities so they can further exploit them.
They also come up with the new ways of attacking code. I'll step away from the topic of the article and tell you about an interesting example. In November 2021, the Cambridge University research group published the results of the analysis of a new Trojan Source attack. This attack may taint software at the code writing stage. The Trojan Source attack is based on special Unicode characters inserted in the comments to the code. These characters change the way bidirectional text is displayed. When such control characters are inserted in comments, some parts of the text will be displayed left-to-right, and other parts — right-to-left. So, if an adversary combines strings with different text directions in one string, text fragments displayed right-to-left may overlap the existing left-to-right text.
This method allows attackers to add a malicious construct to the code and make the text with this construct invisible for anyone who review the code. To do this, an adversary inserts characters in Hebrew/Arabic to a comment or inside the literal. As a result, completely different characters overlap the malicious insertion. Such code will remain semantically correct, but will be interpreted and rendered differently. You can read more about this in the article: "Trojan Source attack for introducing invisible vulnerabilities."
Tainted code can lead to critical losses — from the leakage of personal data to the fall of a satellite directly on the house of the developer who decided not to test the code for vulnerabilities.
It is important to understand that security problems entail not only financial, but also reputational losses for the company. If there is a temptation not to bother and "go with the flow" with the solution of the problem, then I highly recommend reading about Chrysler Jeep Cherokee, which was hacked right while it was driving.
If you want to read other research papers about information security, you can read the reports of Gartner Magic Quadrant.
Now let's go back to our terms. As a response to never-ending threats and ever-growing codebase, developers use AST (Application Security Testing) tools. AST is a process of enhancing application security by identifying vulnerabilities in the source code. Initially, such testing was manual. However, the increase in the number of code lines and the use of third-party open source code, which also needs to be checked, led to the need to automate the process.
The use of testing tools is an important part of the DevSecOps concept. Now let's inspect it in more detail. In the Transparency Market Research's report "Application Security Testing Market — Global Industry Analysis, Size, Share, Growth, Trends, and Forecast 2017–2025", the application security testing market is segmented into the following product classes:
Next, we'll inspect the three types of AST, their pros and cons. Note that this article is not an advertisement for specific products but an overview with general information.
Despite the fact that you can easily google the definition of any abbreviation, I'll still explain them in this article. SAST (Static Application Security Testing) is a process of testing application for errors and vulnerabilities in source code. The application is tested with static analysis.
The main purpose of SAST is to minimize the gap between development and security. A long time ago, when SAST technology was just at the beginning of development, the process of working with SAST looked like this:
Fortunately, modern SAST technologies have greatly simplified this process and allowed developers to test the code.
SAST is rightfully considered one of the main options for finding vulnerabilities in the application's source code. Static analysis is performed at the code writing stage. This allows developers to find errors and vulnerabilities at the early stages of the product's development and reduce the cost of eliminating them. Besides, SAST works with most programming languages.
Other pros of SAST include:
However, SAST is not all roses — it has its cons. One of the main ones is a large number of false positives. Because of this, there is a risk that checking such results will take a long time. Developers of static analyzers pay close attention to false positives and come up with solutions for eliminating them.
Potential vulnerabilities in the source code may cause serious security risks. Using SAST tools reduces these risks and helps control the quality of development.
There are many different analyzers on the world market — both from well-known vendors in the field of security, and from niche players engaged only in the development of SAST:
I'm not implying anything, but you can evaluate the PVS-Studio analyzer and compare it with other SAST tools.
The previous section described static testing, this one will describe the dynamic one. DAST (Dynamic Application Security Testing) is another process of testing applications. DAST imitates malicious external attacks that exploit common vulnerabilities.
The main task of DAST is to detect vulnerabilities before they are discovered by someone other than developers. Such tools look for problem areas by checking access points and simulating user experience. Dynamic testing allows developers to identify vulnerabilities caused by various kinds of code injections into a query (for example, to a web page) or related to an incorrect configuration (the simplest example is authentication with an empty password).
What's the difference between SAST and DAST? Lack of access to the source code.
Let me tell you about the advantages of DAST:
Initially, DAST tools were used less often than static analysis. But due to the increasing demand for security and the high dynamics of the spread of smartphones, in which there are more and more applications related to confidential information, the share of DAST solutions has increased significantly and continues to grow. IndustryARC conducted a research called "Dynamic Application Security Testing Market – Forecast (2020–2025)". According to it, the market of DAST solutions increases by an average of 17.4% per year.
The main companies in this segment, according to IndustryARC:
What do you think, which of these AST types is the most common? If you say that SAST is obviously more common, you will be wrong. But if you say DAST, you'll be wrong again.
According to Grand View Research data on the distribution of analyzer types by sales shares on the global market, the shares of SAST and DAST are almost equal.
Why are these two types of AST the most common? First of all, they exist longer than others, many initial disadvantages have already been fixed and most specialists confidently work with them.
Can we say that these two tools are the same? No.
For greater security of the source code and the product as a whole, developers use both SAST and DAST, since both methods neutralize each other's weaknesses:
The most important thing is to remember that it is not the number of reports that is important for the developer, but the checking and fixing of the vulnerabilities found.
So, now we know what SAST and DAST are. But what's IAST? IAST (Interactive Application Security Testing) is a relatively new (in comparison with SAST and DAST) type of application testing that focuses on detecting security problems in application code. Interactive testing technology allows us to analyze the application from the inside during its operation.
In simple words:
IAST monitors code execution and looks for specific events that may lead to a vulnerability. Next, these events are analyzed in order to check if everything is fine with them and if any error has crept in.
IAST was developed as a modern solution to eliminate the disadvantages of SAST and DAST by combining testing approaches. Interactive testing technology provides real-time detection of security problems by analyzing the traffic and the flow of application execution.
Since IAST works within an application, it can analyze:
Access to all this information allows the IAST mechanism to cover a larger amount of code, give more accurate results and check a wider set of security rules than SAST or DAST.
Besides, IAST is so accurate that it detects more existing vulnerabilities. For clarity, I will give an example of working with OWASP Benchmark coverage:
Despite a certain superiority over SAST and DAST, interactive security testing also has disadvantages.
One of its main disadvantages is that IAST tools may slow down the application. Agents, in fact, serve as additional tools and this leads to a decreased code performance.
It is also extremely difficult to prepare input data and work scenarios that allow you to achieve high code coverage. So, in theory, IAST allows you to cover 100% of code, but in fact this can be hard and labor-intensive. SAST looks more appealing since these tools analyze all branches of the program, regardless of the probability of their execution.
Application Security Testing is a crucial part in the DevSecOps concept, and we can't ignore it in modern world of development. We must use AST to check source code for vulnerabilities, secure inputs, connections and integration between internal systems.
In conclusion, I want to highlight several important aspects of the article: