IAST stands for Interactive Application Security Testing. IAST combines elements of DAST (Dynamic Application Security Testing) simultaneously with instrumentation of the application under test. Legacy IAST scanners include an agent within the test runtime environment (e.g., instrumenting the Java Virtual Machine or .NET CLR) that observes operation or attacks and identifies vulnerabilities. In essence, IAST technology enjoys the benefits of dynamic analysis - the ability to assess a running web application and static analysis – the ability to look at the application's code and inner workings. Historically, IAST was introduced in order to overcome the limitations of SAST and DAST.
While the benefits of using IAST are obvious (better accuracy and coverage), the technology has several limitations, which hindered many organizations from deploying it and eventually leading to the technology not being widely deployed as expected. These limitations include:
IAST requires the deployment of a server-side dedicated agent: Each instance of the application (i.e. either a server, virtual machine or a container) needs to have an IAST agent deployed within it. The deployment process is never easy as it involves delicate software instrumentation. In addition, the agent deployment process must be part of the build automation process, and requires continuous management or maintenance.
IAST agents are language/runtime specific: Since the IAST agent needs to instrument application code, IAST scanners must provide different agents and installation packages per each supported programming language and runtime environment. Some AST vendors that offer IAST capabilities, don’t provide support for all common programming languages and runtimes.
To provide proper coverage, IAST agents must support all development frameworks: Since most modern web applications make heavy use of development frameworks (e.g. Spring MVC, Django, Flask, Ruby on Rails, ExpressJS, etc.), IAST agents must be able to instrument each such framework in order to provide proper security coverage and fully understand the application’s inner workings.
IAST requires DAST: Given how IAST technology works, IAST based scanners cannot operate on their own and almost always require an additional external testing component in the form of a DAST scanner. The DAST scanner’s role is to traverse the application and generate the different attack payloads, while the IAST agent monitors all sensitive functions within the application, essentially validating which DAST payloads managed to exploit a vulnerability within the application. As such, while IAST technology brings a promise of high accuracy and visibility into the inner workings of the application, the quality of the results depends heavily on DAST coverage, and it’s ability to execute the entire application - a known pitfall for all DAST scanners.
Cloud native applications are composed of dozens or even hundreds of loosely coupled microservices, which are oftentimes developed with different programming languages and frameworks. These microservices may run in different locations, on different virtual machines or containers, and in different runtime environments. While the deployment of a single IAST agent in a monolithic application requires a single straightforward installation process, it’s a whole different game when dealing with many microservices, running on different environments and using different programming languages. The task of deploying and maintaining many IAST agents in different environments quickly becomes an IT nightmare. On top of that, your IAST vendor must provide support for all possible frameworks, languages and operating systems - which is not always the case.
Many modern cloud native applications make use of services and components that are offered by public cloud vendors such as AWS, GCP or Azure. For example - data may be stored in AWS S3 buckets, or the application might pass data through cloud messaging queues such as Azure Queue Storage, or GCP Pub/Sub. In such cases, an IAST agent will have severe blindspots where it cannot understand or see application logic or code, since this logic is implemented by the cloud service provider, and oftentimes relies on logic embedded as Infrastructure-as-Code (IaC).
In addition, an IAST scanner will never be able to flag multi-layer vulnerabilities which involve a local vulnerability within your application, in conjunction with a cloud misconfiguration.
As previously explained, modern cloud native applications are composed of many loosely coupled microservices. An IAST agent that is deployed within a single microservice, never sees the big picture - it has a very narrow angle of view. Even if you overcome the challenges of deploying an agent in every microservice, your scanner will only be able to potentially find “local” vulnerabilities within each microservice, however, it will completely be oblivious to the entire flow of the application and its business logic, and as such, will entirely miss multi-service vulnerabilities.
IAST technology brought with it a promise of higher accuracy and the benefits of both DAST and SAST in a single scanning solution, however, the implementation of IAST scanners was always cumbersome and required delicate deployment processes which oftentimes failed. The drawbacks of the technology eventually hindered its adoption by many organizations, and it never saw mass adoption.
The same drawbacks that made IAST hard to deploy and maintain in monolithic applications are amplified when dealing with modern cloud native applications. Such cloud native applications are almost always composed of loosely coupled microservices, developed by different development teams, using a wide range of programming languages, development frameworks and runtime environments. Deploying and maintaining an IAST agent in each server instance, virtual machine or container is extremely challenging to say the least, and in some cases even impossible.
On top of the deployment drawbacks and challenges, modern cloud-native applications, especially those that make use of public cloud services introduce large blindspots for IAST based scanners, which cannot see the logic and code of such services, some of which is implemented as Infrastructure-as-Code (IaC) logic that cannot be instrumented by IAST agents. These blindspots lead to potential false negatives, especially when dealing with multi-layer and multi-service vulnerabilities.
I welcome you to see Oxeye's cloud native application security testing in action.
.jpg)