In my previous two articles in this series on security test automation, I gave a brief insight into SAST and DAST. In this article I take a closer look at Interactive Application Security Testing (IAST), a relative newcomer to the security test automation scene.
The key difference between IAST and the two previous types of application security testing is found in how the tools interact with the products being tested. SAST and DAST are active tools: in order for them to scan code, they need to be triggered either from the Integrated Development Environment (IDE), or from within the CI/CD pipeline. On the other hand, IAST is passive: it is an instrumentation tool that run passively in the background tracing the traffic passing through the application. This means that IAST is dependent on the application being in use, such as when executing manual or automated functional tests. The obvious benefit of this approach is the minimal interaction required to initiate a test. Whenever there is user interaction with the application the IAST tool monitors the data flow to determine how the values are managed by the running application. There is no need to initiate a security scan. Taking this a step further, running IAST continuously within the CI/CD pipeline allows engineers to validate the security of their code whenever they validate the functionality being developed.
This leads to the question of what IAST tracing and how it recognises a vulnerability. In summary, IAST analyses the code at runtime which allows it to inspect how data is being handled internally within the running application. For example, it will identify a value inputed by a user to assess whether it the value is validated or sanitised before being stored in the application’s data store. If the analysis determines that the value is not cleaned by the running application, it flags that the value could be vulnerable to an injection attack for example. In another example, the IAST tools identifies that a value entered into a password field is never encrypted by the running application before it is stored in the application’s data store. This would indicate that the password is vulnerable to being stolen in an attack either while the application is running or when the password is at rest.
The main advantage of IAST over SAST is its greater accuracy. Since IAST follows data within the boundaries of the running application, it can see how the source code interacts with live data. If you recall from the first part in this series, SAST assesses the source code without the context of the running application. This means that IAST is considerably less likely to flag false positives, compared to static code analysis.
Although DAST and IAST analyse the code at runtime, the key difference is that DAST needs to play back automated functional tests replacing expected values with fuzzed values to mimic penetration tests. Therefore, DAST requires a significant amount of work up front in order to initiate a DAST scan. Conversely, the passive nature of IAST and its reliance on instrumentation during the running of normal functional tests, means there is little need for upfront configuration. It is, of course, possible to run functional tests that are already set up as penetration tests while IAST is running which allows engineers to assess how malicious data is handled within the application. Although not specifically designed for this use case, it is potentially an option, although I have yet to see anyone use IAST tools in this way. Indeed, I wouldn’t recommend it.
However, although I have painted a healthy picture of IAST, it does have some weaknesses which need pointing out. One key disadvantage that IAST has over DAST in particular is its lack of comprehensive support for a number of programming languages and frameworks. This is a similar challenge faced by SAST tools which also need to know the underlying application technology in order to work. However, many vendors of IAST and SAST tools continue to increase the scope of languages they support. More popular and established languages such as Java and .NET are covered by IAST, as are the likes of Node, Ruby and Python. Support for more modern languages and frameworks, such as Go and Kotlin, tends to lag behind the advances being made in those technologies. However, this is an area in which IAST is making good progress.
Another point worth noting is IAST’s dependency on the coverage by users of the application under test, whether those users are manual and automated functional test suites or users of the live website. If a particular journey is not covered during normal use or during testing the IAST tool will not identify vulnerabilities present within that journey. Therefore, there is a tendency for IAST to miss true positives during instrumentation if all possible flows through the application are not covered. The obvious way to mitigate this particular risk is to ensure functional test suites cover as many different application paths as possible, including bad, as well as good paths. There is a case that if your functional tests are comprehensive, IAST provides better coverage than SAST and DAST. Regarding the former technology, only source code written by engineers is scanned by SAST tools, based on the technology’s understanding of the framework, while paths through external frameworks and libraries are missed. With regard the latter, DAST struggles with data issues caused by the need to use values that could affect the integrity of the data, thus limiting the scope of the testing it can perform. In some ways, IAST encourages testers to write more comprehensive functional tests in order to increase the coverage of the scans, which is an obvious benefit.
Integrating IAST instrumentation tools into a CI/CD pipeline is relatively easy, but integration into the IDE may not be so effective due to IAST’s reliance on scanning running code, which is most likely to occur during functional or user acceptance testing. However, IDE integration is feasible and if engineers are running their code locally as they develop, IAST tools should provide instant feedback so that engineers can fix the code quickly. Some tools go further and allow engineers to consume outputs from test environments within the IDE, allowing engineers to easily identify the problematic lines of code identified by the scans.
In summary, IAST is a relatively new technology compared to SAST and DAST. Vendors of IAST tools have designed their products to combat many of the weaknesses associated with the more mature application security testing tools and, on the whole, they have achieved this. However, IAST is not perfect: it lacks support for a number of modern languages and technologies used by engineers, although this is an area which is seeing notable improvements; it is dependent on instrumenting a comprehensive set of manual or automated functional tests to guarantee full code coverage, although conversely, it encourages testers to write more functional tests; and IAST is better suited to phases of the software delivery lifecycle in which code is running, such as in test environments, although it can support engineers running code in their IDEs.
Next week, I will examine Runtime Application Self-Protection (RASP) tools.