The application security testing (AST) world is made up of different solutions, all with one ultimate goal – to protect software from hackers, and their attacks. SAST and DAST are perhaps the two most common and well-known solutions. In the last few years, a newcomer has gradually received more-and-more attention – IAST.
So what is IAST and how does it differ from SAST and DAST?
What is IAST?
First things first – IAST stands for Interactive Application Security Testing.
Analyst firm Gartner defines IAST as follows: “Interactive application security testing (IAST) uses instrumentation that combines dynamic application security testing (DAST) and static analysis security testing (SAST) techniques to increase the accuracy of application security testing. Instrumentation allows DAST-like confirmation of exploit success and SAST-like coverage of the application code, and in some cases, allows security self-testing during general application testing. IAST can be run stand-alone, or as part of a larger AST suite, typically DAST.”
This definition is quite broad, allowing for a variety of solutions to be classified as IAST products. To really define what IAST is, we need to make a distinction between two types of IAST – Active vs. Passive. Both active and passive IAST rely on an agent instrumented within the application itself during the testing stages of the SDLC. However, the differences between the two methodologies are significant in terms of the technology itself, in addition to how well they fit into fast-paced development environments.
Active IAST, or also known as “Induced IAST”, requires a DAST solution in order to provide any real value. By instrumenting the application with an agent, the DAST engine will run its attack simulation and depend on a response from IAST to validate an existing vulnerability. While this approach provides results with great accuracy, it requires its own testing environment and cannot be automated. Therefore, this approach is viewed as unfit for fast-paced CI/CD and DevOps environments.
Passive IAST, or more correctly termed “Self-sufficient IAST”, was actually built to overcome the caveats of active IAST – by addressing the need for quick application security testing in fast-paced DevOps environments. Passive IAST also requires instrumentation of the application in the testing environment. But rather than actively running dedicated tests/attacks, it will leverage any form of functional testing to collect data and deliver accurate security findings in zero time. Whether tests are automatic or manual, the passive IAST will “listen in” and continuously report on any findings.
How is IAST different from DAST?
DAST tools find vulnerabilities on running applications by externally attacking the application. Coverage is limited to reflective types of vulnerabilities, since DAST solutions are essentially blind as to what is happening inside an application. Some of the challenges experienced with DAST include moderate false-positive rates, an increased number of testing cycles, and increased testing duration. Finally, DAST results offer no code-level guidance as to where software vulnerabilities are located, making it difficult for developers to easily fix identified vulnerabilities. DAST tools can’t effectively achieve the fast turnaround times required for integration into stringent CI/CD workflows, unlike IAST, which produces results in real time.
How is IAST different from SAST?
The main difference between the two pertains to name – Static vs. Interactive. SAST, which stands for Static Application Security Testing, analyzes the application source code to identify vulnerabilities. SAST solutions are great at providing code-level guidance as to where and how to fix vulnerabilities in source code. SAST fits well into integrated development environments (IDEs), issue trackers, and build tools to support CI/CD workflows. However, unlike IAST, SAST is blind to how all the pieces of an application work together and operate at runtime, so it can’t detect vulnerabilities in running applications that attackers may be able to exploit. In comparison, IAST performs its testing during runtime, being capable of detecting vulnerabilities in running applications.
The easiest way to think about the three different technologies, in my opinion, is to think of sushi. Yes, that’s right, sushi. DAST is like a regular maki – seaweed on the outside. DAST performs all of its testing from outside of the application. SAST is like an inside-out roll. It performs all of testing on the source code itself. Finally, IAST is a bit of both – inside out and outside in. Essentially, IAST combines the SAST philosophy of examining from within, with the DAST view of the running application
Want to learn more? Join our upcoming What the Heck is IAST webinar