If you are someone who’s submitted, be it intuitively or after unnecessary consideration, to the idea of DevSecOps, chances are discussions over security tooling is a recurrent feature of your work week. One such unresolved discussion people, within my circle, swear to have had repeatedly revolves around IAST and DAST tools. The crux of it being: Which one is better DAST or IAST? More alarming than not having an answer for a particular question is trying to answer the wrong one. In the rest of this article I want to steer my readers, within the application security domain, toward a better question: Which tool is better for me, DAST or IAST? And to best equip you to answer the same.But before we begin, for those of you new to IAST or DAST, here is a quick 101.
Dynamic Application Security Testing (DAST) is a process of testing an application during runtime. The purpose of such a test is to identify security vulnerabilities, while the application is operating in the environment that it was built for. This can either be carried out manually or using DAST tools. These tools crawl and test the application from the outside-in, and with appropriately designed test cases can simulate security use cases effectively across the application. Good examples of a DAST tool would be OWASP’s ZAP, BURP Suite, Arachni etc.
Interactive application security testing (IAST) uses a concept commonly know as “instrumentation” that combines DAST and Static Analysis Security Testing (SAST) techniques to increase the accuracy of application security testing. Instrumentation involves working with an "agent-like" approach, where an IAST agent is run on the target application server to actively monitor the application’s behavior while the application is being used. The agent hooks itself to various functions and calls of the application and identifies security issues as its able to see inside-out (both from code and flow of traffic into and out of the application).There are few factors that need consideration when evaluating a tool fit for your SDLC pipeline. Let’s study them under three silos: People, Process, and Technology.
People are one of the key pillars of DevSecOps. The tool shouldn’t cripple their efficiency and hence it must not be too complex or difficult to adapt to. There must not be too much of an incremental effort involved to develop a good understanding of the tool, its capabilities, limitations, and learn its support system to help enable them to easily integrate it as part of their agile application building. Therefore, when you choose a tool, you need to ask yourself the following questions:How much expertise does the tool require to integrate or manage as part of the pipeline?Is the necessary support required to ensure smooth functioning of the tool provided by the tool supplier or other third party sources?What is the open-source support for configuration and fixing errors?Does the tool have a user friendly dashboard and provide comprehensive metrics?Here are my answers for the above questions.It doesn’t need much expertise to get IAST up and running. It is an almost plug and play system. However, you might need the supplier’s help with setting up important configurations and necessary parameters, such as policy configurations, input parameters, etc. You’ll also need to deploy it on your server, which might force you to buy addition hardware. DAST tool set up is simpler still. You can just use the web application URL to run a default policy scan or scripted walkthroughs. You can do so right from your computer, without the need for additional servers or systems.IAST tools are mostly proprietary and therefore support for the same is limited. DAST tools on the other hand, have a strong open-source presence and hence have community support on tech forums and other similar spaces. So, your engineering team would probably find it easier to find fixes for configuration and system errors while using DAST tools.User friendliness and comprehensive nature of metrics vary from tool to tool and supplier to supplier therefore I won’t make a distinction here.
For any DevOps pipeline to remain efficient, the security integration process must be seamless and easily operationalized. It should also be resilient to your team and company goals changes. Here are few questions to ask yourself while choosing a tool:How easy is it in terms of time and effort to integrate the tool into your pipeline?What is my current security and DevOps maturity?Which is more important to you: Continuous Integration? Continuous deployment?Where in your pipeline do you want it?How easy is it to automate?Is it compatible with our existing automation tests such as QA tests, automated web crawlers, or unit testing?
Since IAST is a plug & play tool, and dependency on tool supplier notwithstanding, is effortless to integrate into your pipeline whereas only a few DAST tools even have the capability to be integrated as part of a tool chain. Generally speaking, however, it does take more time to integrate a DAST tool compared to an IAST tool. Also worth noting here is that with a DAST tool you are far more flexible to set policies and modes of testing as per your application needs.When it comes ease of automation it’s hard to make a distinction as different tools behave differently. The positive thing from a DAST perspective is the presence of readymade scripts, which are used to guide the tool for increased depth and efficient testing, and other shared resources online, making automation easy unlike IAST tools which may require you to look at your supplier for help.Another important factor to consider is what is more important to you as part of your application release cycles: Continuous delivery, Continous integration, or Continuous deployment? Some companies target continuous delivery, which has a very short sprint and the code is ready for delivery at any given time. While, some companies target continuous deployment, where any changes made to the code is deployed right away.
The first and foremost here is to ensure that tool actually does improve security and doesn’t dramatically reduce the agility of your Dev pipeline. So, the questions you ask yourself here are:How accurate is the tool? What percentage of the results are false positives?How long does it take for the tool to run? Can it run continuously in real time?Does it support your tech stack? Does it have the necessary plugins or extensions?Does the tool have the ability to both identify security vulnerabilities and determine whether they can be exploited? (Actionability)IAST has close to 100% accuracy. It barely has any false positives. DAST tools on the other hand are riddled with false positives that mandate manual analysis to filter out false positives. In this regard, therefore, IAST is far superior to DAST.Tech stack: One of the main disadvantages of IAST is that it can only test applications which have languages that their library supports. The current IAST tools collectively only support few languages like Java, python, ruby, node js, and .net. So, if you have applications that use Go lang, for instance, IAST will be useless; if your application has dependencies from other languages, only some of which are covered by IAST are scanned and rest are ignored, making IAST less effective against the entire application.DAST on the other hand is language agnostic.With respect to speed and continuity, IAST runs on real time and hence is faster than DAST. DAST is very slow, and takes hours to complete a test. One thing that does reduce time with DAST is its flexibility to modify scan policies to only include what you want.Another advantage IAST has over DAST is that, following a test, IAST tools find flaws and point to the vulnerable lines of code. With DAST, it’s hard to pinpoint where the flaw is.What I want to elucidate in this article is that it’s not easy to conclusively pick IAST over DAST or vice versa without context. They both have different features and serve different purposes that require close attention before making a decision. I hope through this informative piece and your automation pipeline considerations you would be able to pick out security tools that work best for you. If there was a consideration I missed or overlooked let me know with a comment below.
