IAST: A New Approach for Agile Security Testing

Static Application Security Testing (SAST) tools such as Fortify, Veracode, Checkmarx or IBM App Scan Source Edition have been available on the market now for a while. All of them have their specific pros and cons. But there are certain problems that leak all of these static scanning technologies. Here are three important ones:

  • False Positives: No matter what vendors might say, static code scans will lead to a number of false positives, especially the first scan that is performed on an application
  • Ownership: Who should be in charge of performing tests? Static code scanning often results in a large number of findings (not all of them false positives of course). Therefore, there need to be at least one (internal) tool expert if he/she actively performing the tests or will helping others with it.
  • Context: It is often hard to map a specific finding from a static code scan to application context (e.g. a specific url) where this could be exploited.

These might not be problems for all companies, and in fact SAST tools do a very good job in many organizations. Others do struggle a lot using such technologies though. Especially when such an tool expert is missing (e.g. when a security scanning tool should be operated within QA by non-security personal), implementing SAST technologies often doesn’t lead to the expected (or promised) situation.

What IAST is

Therefore, a I while ago, a new type of very promising technology has been emerged that could these problems: IAST. IAST stands for Interactive Application Security Testing and is another product group term that has been invented by Gartner.

IAST can be easily described as dynamic code scanning tools, whereas SAST are always static code scanning tools that are performed against either source, byte or binary code. It usually works by instrumenting (weaving) the deployed bytecode (in case of a Java application) or IL code (in case of a .NET application) during runtime and on the application server. The advantage of this: It allows you to analyze applications during runtime. All code that is executed by the application server will be analyzed and can be linked to the context (e.g. the Url as well as the relevant SQL statement).

Especially when it comes to agile security testing where continuous security testing becomes more and more important, the IAST approach offers huge advantages.

The technology itself is much older and has been widely known in the QA market for a while now. The first product in the security market was to my knowledge Fortify PTA (Program Trace Analyzer) which was available at least in 2008. It was a very exciting technology, but perhaps a bit early back then, so it was taken from the market in 2012. What changed a lot in the recent years was that products become much more mature and “enterprise ready” if you want.

And so it is that almost every SAST / IAST vendor is currently working on building or acquiring a IAST solution or has already one in its portfolio. Since it is not clearly defined what functionality an IAST tool has to offer, the differences between those solutions can be huge. For instance, some DAST products may just be extended by an additional server-side agent that improves the results of a DAST (Dynamic Application Security Scanning) scan. A couple of vendors now offers solutions with “IAST technologie”. When we look a bit deeper into them, it becomes clear, that we basically must distinguish two approaches:

IAST Light (Active)

The first approach are basically DAST solutions that have an additional agent installed on the application server to improve test results. The architecture more or less looks like this:

iast light architecture

Many vendors such as HP, IBM and Accunetix extended there tools with this function. The most sophisticated implementation of this approach is to my knowledge Seeker that has been recently acquired by Synopsys (Coveritry) from Quotium. Seeker is basically an enterprise scanning solution that integrates both DAST and IAST capability. It thereby actively runs continuous security tests (“attacks”) such as SQL Injection against a Web application and identifies (that different to a classic DAST solution) potential vulnerabilities with its agent that observes the application from within the application server.


Seeker is very easy to use (it even casts videos of vulnerabilities it identifies) and allows to be integrated in automatic functional testing tools such as Selenium or HP QTP and offers management reporting and dashboard functionality as well as the integration into existing systems such as Sonar.

Full IAST (Passive)

The only “full” IAST tool on the market is to my knowledge currently Contrast IAST from Contrast Inc. The approach of Contrast IAST is a bit different to tools like Seeker. The main differnce is that Contrast does not actively performs attacks against a web application but analyzes instrumented code purely passively. This is in fact a huge advantage, since it will not affect other testing activities that run at the same time and only business testing (manual or automatic) are required to trigger security tests:

iast architecture

I therefore call this a full IAST approach.

The integration and execution of Constrast IAST is extremely simple: It just need to be activated on the application servers that are used for testing once. After that you assign a license to the application you want to have tested on the Contrast management console and you are good to go. Whenever someone (or some tools) run tests against this application contrast will analyze the data flows for potential security problems and reports them on the central security console, to a central system such as Sonar or by custom alerts directly to an assigned mail address.

The dashboard view looks like this:
Contrast WebGoat Vulnerabilities

As we can see, the reported results are pretty comprehensive and can be easily tested and linked to the vulnerable code.


First of all, we see that there are major differnces between different IAST tools on the market. Some are more or less just an improvement of a DAST Tool (“IAST Light”), whereas “Full IAST” tools not only just provide just an alternative to SAST testing but a solution to major problems the industry currently stuggles with a lot (e.g. false positives and required security experts). Especially when it comes to testing security in an agile or even DevOPS environment.

However, in my opionion, there is a market for both technologies: IAST tools are (at least at the moment) more expensive reagarding licensing compared to SAST tools, they require the application to be executable and access to the runtime environment, provide less test cases then commercial SAST tools to name just a few reasons for this.

About Matthias Rohr

Matthias Rohr, CISSP, CCSLP, CISM, CCSK, is Founder and CEO of Secodis GmbH. Matthias began working in this field in 2004 and is since a frequent speaker on international conferences, book author and an active OWASP constributor and recently published his first book. He lives and works in Hamburg / Germany.
This entry was posted in IAST, SAST, Security Test Automation. Bookmark the permalink.

2 Responses to IAST: A New Approach for Agile Security Testing

  1. Erik Klein says:

    I have memories of Fortify PTA … actually it had a few names and incarnations …
    1. Fortify Tracer
    2. Fortify DEA (Dynamic Execution Analyzer) … very short-lived name
    3. Fortify PTA (Program Trace Analyzer)
    4. Fortify SecurityScope
    5. WebInspect Agent

    The first four were licensed products; WebInspect Agent is now given away as part of a WebInspect license.

    #1 – #3 used post-build / pre-deploy bytecode injection in which you needed to run an extra step against the JAR/WAR/EAR or .EXE to do a one-time bytecode injection process. Then it would get deployed. Many people were very nervous about this because they were witnessing their application getting modified via AOP. There was a lot of push back.

    #4 – #5 were the result of a rearchitecture that occurred in 2010 that eliminated the manual bytecode injection step and instead used an agent technology that extended the JVM or CLR and did real-time bytecode weaving of the deployed application. This was better from a developer’s perspective (they didn’t have to watch their code get changed) but it produced immense pushback from Sys Admins and Operations folks who were not yet used to agents being installed on application servers. Thanks to the APM market, agents are now readily accepted so this pushback is much less … as a matter of fact, there are so many agents that there are issues with .NET CLR only supporting one profiler so alternative approaches are being developed.

    The difference between Active and Passive IAST is small from a technology perspective and huge from a end-user perspective.

    Active IAST is directly tied to a DAST product and effectively allows an AppSec expert who uses the DAST product to get more accurate and thorough results. This is a good thing. That said, it doesn’t change the process of identifying security vulnerabilities … it still is a snapshot in time, generally done infrequently, and requires an expert for configuration and triage.

    Passive IAST is not reliant on any exploitation whatsoever and simply analyzes any thread that runs through the JVM, CLR, or Node engine, which means that any/all system usage/testing done in the SDLC invisibly finds security vulnerabilities without any extra steps or experts. Direct real-time developer consumption of results is commonplace due to accuracy. Results are always up to date.

    Thanks for the post.

  2. IAST security is best used in conjunction with other testing technologies. An effective application security solution will not rely on a single testing technology

Leave a Reply

Your email address will not be published. Required fields are marked *