Application Security Testing. How not to get confused between SAST, DAST, and IAST

Informational security

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:

• it is not universal?for various spheres of development;
• some cybersecurity experts?consider this system outdated?and, as a result, dangerous.

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.

AST

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:

• Static Application Security Testing (SAST),
• Dynamic Application Security Testing (DAST),
• Interactive Application Security Testing (IAST),
• Mobile Application Security Testing (we won't inspect this class in this article).

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.

SAST

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:

• security specialists tested the code for vulnerabilities. Then they passed the results of the preliminary scan to the developers to fix the code;
• after receiving the results from the "security guys", the developers dealt with a large volume of unclear results and false positives that often appear at the later stages of the SDLS (Software Development Life Cycle).

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:

• the ability to integrate static analysis into the development process, in the IDE;
• detecting critical vulnerabilities, such as buffer overflow, SQL injection, Cross-Site Scripting (XSS) and others;
• and the coolest one — indicating the exact location of a suspicious code fragment. This is especially important for large projects with hundreds, thousands, and millions of code lines.

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:

• Checkmarx,
• PVS-Studio,
• Micro Focus,
• Synopsys,
• Veracode and others.

I'm not implying anything, but you can evaluate the?PVS-Studio?analyzer and compare it with other SAST tools.

DAST

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:

• unlike SAST, it allows developers to detect problems at runtime. These may be authentication and network configuration flaws, or problems that occur only after logging in;
• finds errors that occur when the user is working with the application;
• allows developers to test the application and identify flaws that were not found by regular tests.;
• DAST is not tied to programming languages.

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:

• WhiteHat Security,
• Synopsys,
• Veracode,
• IBM,
• Accenture,
• Pradeo Security Solutions,
• Trustwave Holdings and others.

SAST vs DAST

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:

• DAST works with different sets of input data, which makes it possible to identify their incorrect/unsafe processing;
• SAST is good at detecting errors in the source code, but issues a large number of false positives;
• DAST technologies do not allow developers to mark coding errors exactly up to the line number of the code;
• SAST is easy to integrate into working on a project and automate processes. This helps eliminate some of the problems associated with testing the code base for security;
• DAST understands function calls and arguments;
• SAST can work with function calls and arguments, but only partially.

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.

IAST

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:

• SAST works with code without running the application;
• DAST can work with a running application but without access to the code;
• IAST works with code within a functioning application.

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:

• application code;
• data flow;
• configurations;
• HTTP requests and responses;
• libraries, frameworks and other components;
• information about the internal connection.

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:

• some IAST tools achieve 100% coverage without false positives;
• SAST offers only partial detection (no more than 80% of the OWASP Benchmark) and issues a lot of false positives;
• DAST tools provide a low level of detection — about 10-15% of the OWASP benchmark.

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.

Conclusion

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:

• there's no universal solution that ensures 100% development security. Nevertheless if you use testing tools at the early stages of development, you will easily find potential vulnerabilities and prevent them from turning into real security threats.
• SAST and DAST are not mutually exclusive tools. The joint application of both technologies at the appropriate stages of development will allow us to achieve the best indicators of source code security;
• SAST tools are designed to be used in continuous integration. DAST tools are often mistakenly perceived as unsuitable for automation, but contrary to such opinions, advanced DAST solutions are successfully used in CI/CD pipelines by many enterprises;
• implementing IAST in SDLC is often more complicated, but it's worth it because of the versatility of the tool;
• IAST combines both pros and cons of SAST and DAST;
• AST approaches should be applied to any third-party code in development. There is no guarantee that a third-party component is secure, regardless of whether it is commercial or open-source.