Interactive Application Security testing (IAST) first emerged as a concept in the early 2010s as application security companies looked to improve on static (SAST) and dynamic (DAST) testing by either combining results together, or looking for some kind of best-of-both-worlds approach.
Since that time, IAST has grown to about 20% of the AST market and is predicted to gain a larger share of this rapidly growing market in the coming years. However, in my opinion, the way IAST is understood and deployed today means that the acronym needs a tweak.
Originally, when the category was new, the word ‘Interactive’ in IAST was used to mean one of several things: either an interaction between dynamic and static testing; or an interaction between a human tester and an instrumented, running application under test; or the interaction between a dynamic test-case generator and the signals from an instrumented application.
However, with the imperative for security testing to “shift left”, i.e. integrate earlier in the development lifecycle and provide immediate security feedback to developers, users of IAST are frequently opting for another paradigm: instrument an application in a development build and execute automated test cases provided by developers or security analysts. This is carried out automatically and integrated into the CI pipeline without any interaction at all.
At Cryptosense we see our Analyzer IAST tool for cryptography deployed more and more in this way, something it’s well adapted to as our instrumentation is deliberately lightweight to avoid performance or stability issues (to understand why IAST is particularly good for testing crypto, see this recent article). Other IAST vendors seem to be seeing the same thing.
Since the essential added value to automatic testing comes from the instrumentation and subsequent analysis, and we’re actually trying to minimise the need for interaction, maybe it’s time to rename IAST as Instrumented Application Security Testing?