Interactive application security testing (IAST)

What is interactive application security testing?

The term interactive application security testing (IAST) applies to security testing where the testing tool interacts with a running application and observes it from the inside in real time. Note that the term IAST can refer both to the security testing methodology and to tools that use this approach.

Interactive application security testing solutions are designed to test web application frameworks and APIs. Very few IAST solutions exist for mobile and desktop applications.

IAST is also referred to as gray-box testing.

How does IAST work?

Interactive application security testing tools work by running checks on the codebase of an application as the code is being executed by the web server or application server. This AppSec technology fills the gap between static application security testing, which involves checking static (not running) code, and dynamic application security testing, which checks the application from the outside only.

IAST may be implemented as part of automation workflows (CI/CD pipelines) but is just as useful during scheduled or manual application testing processes. One of the biggest benefits of IAST is that, just like static code analysis, it is able to pinpoint the problem to the line of code. If the IAST tool works on bytecode, it is usually able to reverse-engineer the intermediate code and isolate the issue in the corresponding source code.

Note that application security tools, unlike anti-malware tools, do not perform remediation. Their job is only to find typical security issues in an application, such as SQL injection and cross-site scripting (XSS) vulnerabilities – not to fix them. Any security risks that are found need to be eliminated manually by development teams.

Types of interactive application security testing tools

Because the concept of IAST is relatively new compared to DAST and SAST, and was initially devised to cover a variety of approaches by different vendors, the term may apply to cybersecurity tools that differ significantly in what they do. In general, there are three classes of IAST tools available on the market.

Passive IAST

Most tools provide only a sensor that attaches to the running application. If this sensor notices something suspicious as the application is running, it reports it to the IAST solution’s dashboard. Such tools are usually induced by QA testing (unit tests) and cover only the code that is included in QA testing.

Active IAST

A large selection of IAST tools on the market are delivered by DAST makers but as separate (non-integrated) products, often called DAST-induced IAST (a term used originally by Gartner). These use DAST to activate IAST sensors but do not collate data from the two sources. They work just as if you took a passive IAST solution and combined it with a completely separate DAST.

True IAST

A handful of tools on the market go a step further than active IAST and these have been dubbed true IAST. This is because for these tools, there is actual interaction between the inducing element (a DAST scanner) and the IAST sensor. The two communicate and influence each other to provide better test results, attain a very low false-positive rate, and fully confirm security vulnerabilities. All the DAST and IAST results are also collated into a common reporting interface. Invicti and Acunetix by Invicti are examples of such true IAST tools.

Types of interactive application security testing sensors

All IAST tools need sensors to monitor the running application, but there are a few different ways of implementing the sensors. That is why there are two broad classes of IAST sensors:

Invasive sensors

Most IAST tools on the market, especially passive IAST, work on the basis of invasive sensors. This means that for the IAST tools to work, the developer must introduce changes to the source code – this is called instrumentation.

The downside of this approach is that the business must maintain two separate branches of their source code: one with IAST sensors and one without them. This introduces extra complexity and can lead to organizational problems.

Non-invasive sensors

A few IAST tools use a different method of monitoring. Their sensors are not placed in the source code and don’t need any code modifications. Instead, the sensors attach directly to the server-side runtime environment and “listen in” on the code as it is executed by the web server or application server.

Tools that use non-invasive sensors are able to scan applications without any changes to the source code or configuration. In practice, this means that developers don’t need to prepare separate code branches for security testing.

Invicti and Acunetix by Invicti are two examples of tools that use non-invasive sensors.

Advantages and disadvantages of interactive application security testing

Interactive application security testing should be a part of a complete security testing program that includes other web application security testing methods, such as dynamic application security testing (DAST, or black-box testing), static application security testing (SAST, or white-box testing), software composition analysis (SCA, used to analyze open-source components), RASP (runtime application self-protection), and manual penetration testing. IAST has several advantages over other testing methodologies.

• Compared to SAST tools, IAST adds the ability to examine the application as it runs, not just analyze its static code. This means more precise results with far fewer false positives because IAST has access to runtime information, such as the configuration and the data flow.
• Compared to DAST tools, IAST can not only identify a vulnerability in a specific element (for example, a form on a page) but also isolate the location of its root cause in the source code and/or bytecode.

Interactive application security testing also has some disadvantages in relation to other application security testing methodologies.

• Compared to SAST tools, IAST cannot be applied very early in the software development lifecycle, for example, in the development environment (IDE) itself. It needs the application to be up and running, so IAST testing can start at the same time as DAST testing but not earlier on in the development process.
• Unlike DAST tools but similar to SAST, IAST sensors are programming language-specific, with most products focusing on Java and very few, for example, on PHP. For less popular languages, IAST testing may not be possible at all if no sensor is available.

Keeping these advantages and disadvantages in mind, it is best practice to only use IAST together with DAST and/or SAST. When using active IAST or true IAST, this is a natural combination because these types of IAST require DAST to run.

IAST accompanying technologies

The sole function of interactive application security testing is to scan the running application code and find vulnerabilities. However, in most environments, that is not enough. That is why IAST tools either offer extra functionality or come bundled with accompanying software, which offers the following functions:

• Vulnerability assessment: In larger organizations, the number of vulnerabilities can be in the thousands, making it impractical for security teams to manually verify endless lists and prioritize issues. Vulnerability assessment solutions automatically assign priorities to vulnerabilities discovered by IAST based on different factors such as severity, ease of exploitation, or even the business importance of a particular asset. This lets security teams focus their remediation efforts on security risks that are most likely to lead to severe consequences such as a data breach.
• Vulnerability management: If the number of vulnerabilities is large, it is almost impossible to manually track issue resolution status. That is why IAST tools need to be tightly integrated with issue-tracking solutions that allow security teams to manage vulnerabilities.

Many IAST providers offer bundles that include not just vulnerability assessment and vulnerability management (usually as separate applications within the same environment) but also other types of application security scanning, such as DAST and IAST.

Some vendors provide a combination of DAST, IAST, vulnerability assessment, and vulnerability management in a single solution. DAST and IAST are a natural combination and professional DAST tools come with vulnerability assessment and management functionality built in. Examples of such solutions are Invicti and Acunetix by Invicti.

How to use IAST?

There are two distinct methods to implement IAST in an agile DevOps/DevSecOps workflow, depending on the type of IAST:

• If you’re using passive IAST, you should integrate it with your QA testing environment, for example, Selenium. You should have your QA testers design unit tests that cover the entire functionality of the application so the IAST sensor can reach every corner. This is, however, hard to do in practice and businesses often accept that parts of the application, such as the administrative back-end, are not IAST-tested.
• If you’re using active/true IAST and you already have a DAST solution integrated into your SDLC, you don’t have to do anything to integrate IAST. If the DAST solution collates results from IAST and DAST, IAST testing is simply included as part of DAST testing. You will have extra information from IAST checks included in the relevant DAST checks.

Frequently asked questions

Related blog posts

• DAST, IAST, SCA security testing: Deeper coverage in a single scan

Written by: Tomasz Andrzej Nidecki, reviewed by: Zbigniew Banach