Lecture
According to statistics, 90% of security incidents result from attackers exploiting known software flaws. Naturally, eliminating vulnerabilities during the software development stage significantly reduces information security risks.
The application security testing (AST) technology market consists of the following categories:
1st generation
2nd generation
To eliminate vulnerabilities during the software development stage, a whole range of technologies have been created to help developers identify security flaws early, removing them before the product is released. These technologies include:


SAST (Static Application Security Testing) — «white-box» testing, has existed for more than ten years. It allows developers to find security vulnerabilities in an application's source code at early stages of the software development lifecycle. SAST also helps ensure compliance with coding guidelines and standards without actually executing the underlying code.
Why is it called static? Because the test is performed before the program is run and executed. SAST can help identify weak spots in your program before the world finds them.
SAST uses a testing methodology to analyze source code in order to detect any traces of vulnerabilities that could provide a backdoor for an attacker. SAST tools typically analyze and scan the code in addition to how it will be compiled.
The SAST process is also known as white-box testing. Once a vulnerability is found, the next course of action is to review the code and fix it before the code is compiled and deployed to production.
DAST (Dynamic Application Security Testing) — «black-box» testing, can detect vulnerabilities and weaknesses in a running application, usually a web application. This is achieved by using fault-injection techniques within the application, such as feeding malicious data into the software, to reveal common security vulnerabilities such as SQL injection and cross-site scripting.
DAST can also shed light on runtime issues such as:
These cannot be detected through static analysis.
This tool is very different from SAST, since DAST uses a black-box testing methodology: it performs its vulnerability assessment from the outside, since it has no access to the program's source code.
DAST is used during testing and quality control in the SDLC.
SAST works well when it comes to detecting an error in a line of code, such as weak random number generation, but is generally not very effective at detecting data-flow flaws. In addition, SAST solutions are known for producing a large number of false positives or false negatives.
Some success in reducing or completely eliminating false positives has been achieved using so-called abstract interpretation. However, to achieve the best results, abstract interpretation algorithms must be tailored to:

Despite all of SAST's shortcomings, it remains a favorite among development teams to this day.
The main selection criterion is the ability to scan the project at the code level.
This makes it possible to find flaws at early stages of product development, which helps reduce the cost of fixing them.
Moreover, SAST can be automated and transparently integrated into a project's workflow. This eliminates some of the problems typically associated with application security testing. This feature stands in sharp contrast to DAST, where large projects require building a separate infrastructure, running special tests, and launching multiple instances of the application in parallel with different input data.
However, DAST understands function arguments and calls, which cannot be said of SAST.
PHP Malware Finder (PMF) is a standalone solution that helps you find possible malicious code in files. It is known to detect tricks, encoders, obfuscators, and web shell code.
The Progpilot static analyzer lets you specify the type of analysis, such as GET, POST, COOKIE, SHELL_EXEC, etc. It currently supports the suiteCRM and CodeIgniter frameworks.
Arachni is a high-performance security scanner built on Ruby for modern web applications. It is available as a portable binary for Mac, Windows, and Linux.

Not just a basic static website or a CMS-based website — Arachni can also fingerprint the platform. It performs both active and passive checks.
Some of the vulnerabilities it detects:
You have the option to get an audit report in HTML, XML, plain text, JSON, YAML, etc.
Arachni lets you take scanning to a new level using plugins. Check out all of Arachni's features and download it to try them out.
RIPS is one of the popular PHP static code analysis tools that can be integrated into the development lifecycle to find security issues in real time. You can classify the findings by industry compliance and standard to prioritize fixes.
IAST (Interactive Application Security Testing) — interactive application security testing. SAST and DAST are relatively old technologies, so there is a view that they are not the best choice for testing modern:
For example, SAST performs poorly with:
And these are present in practically every modern application.
Static tools only see the application's source code that they are able to follow. Moreover, libraries and third-party components often cause static tools to get stuck, producing messages such as:
The same applies to frameworks. A static tool will not find anything wrong in:
All because it cannot understand their structure.
IAST was designed to address the shortcomings of SAST and DAST by combining elements of both approaches. IAST performs all analysis in real time:
Because IAST works inside the application, it can analyze:
Compared to SAST or DAST, access to all this information allows the IAST engine to:
Features of IAST
RASP (Run-time Application Security Protection) — runtime application security protection. Like IAST, it works inside the application, but it is more of a security tool than a testing tool. It attaches to the application or its runtime environment and can monitor the application's execution. This allows RASP to protect the application even if network perimeter defenses are breached and the application contains security vulnerabilities.
RASP allows the application to perform continuous security checks and respond to attacks in real time, terminating the attacker's session and alerting defenders to the attack.
The main problem with RASP is that it can give the development team a false sense of security. Some security measures may be neglected on the grounds that — «If we miss something, RASP will fix it».
Another drawback of RASP technology is degraded application performance. IAST has the same drawback. Although performance-boosting techniques can minimize the slowdown, an unpleasant aftertaste still remains.
All of the technologies listed above have their own strengths and weaknesses, so combining them with one another provides a higher level of security. However, using even a single technology at early development stages makes it possible to build more secure software, and, more importantly, to do so faster and at lower cost than tying all tests together after already running into a problem at later stages.
Features of RASP
SAST, DAST, and IAST are excellent tools that can complement one another without any issues, as long as you have the financial backbone to support all of them. Security experts always advocate using two or more of these tools to ensure better coverage, which in turn reduces the risk of vulnerabilities in production.
| SAST | DAST |
|---|---|
| This is white-box testing, where you can see the framework, design, and implementation of the program's source code. The entire application is examined from the inside. This type of testing is often called the developer's approach. |
This is «black-box» testing, where you have no access to the internal environment, and cannot see the program, its source code, or design. Application testing is done from the outside. This type of testing is often called the hacker's approach. |
| SAST does not need to be installed, but it needs the source code in order to operate. It typically analyzes the source code directly, without executing the program at all. |
DAST needs to be deployed on the application server and does not need access to the source code before operating. It is simply a tool that is run to scan the program. |
| This is one of the tools used to detect vulnerabilities very early in the SDLC. It is applied as soon as the code is written. It flags vulnerabilities right in the IDE. |
This is used only after the code has been compiled, to scan the entire program for vulnerabilities. |
| This tool is not expensive, since vulnerabilities are typically found very early in the SDLC, which makes them quick to fix before the code is put into production. | This tool is expensive because vulnerabilities are usually found toward the end of the SDLC. Remediation is generally not performed in real time, except in emergency cases. |
| This tool scans only static code, which makes it difficult to identify any runtime vulnerabilities. | This tool scans the program using dynamic analysis to identify vulnerabilities at runtime. |
| This supports any kind of program. | This only scans applications such as web applications; it does not work with other kinds of software. |
| IAST | RASP |
|---|---|
| This is used mainly as a security testing tool. It looks for security vulnerabilities. | This is used not merely as a security testing tool, but to protect the entire application by running alongside it. It monitors the program against any attacks. |
| This maintains SAST's accuracy by using runtime analysis results from SAST. | This is a tool that detects and blocks threats in real time. This activity requires no human intervention at all, since the tool lives inside the main application and protects it. |
| This is gradually being adopted and requires agent deployment. | This is not yet widely adopted and requires agent deployment. |
| Language support is limited. | This is language- and platform-independent. |
| This tool is very easy to integrate for source code analysis, runtime monitoring, and all the frameworks that make up the program. | This tool integrates seamlessly with the application and does not depend on any network-level defenses such as a WAF. |
| This tool delivers the best of a combination of SAST and DAST features, helping it identify vulnerabilities on a broader scale. | Covers a wide range of vulnerable spots |
Despite some limitations you may notice in technologies such as SAST, DAST, IAST, and RASP, using these automated protection tools always ensures more secure software and will save you the high cost of fixing a vulnerability discovered later.
Which is the best approach or security tool among these four?
Answer: Usually, the best approach is to use all of these tools, if your budget allows it. By implementing all of these tools, you will make your software stable and free of vulnerabilities.
Comments