DAST or IAST: Ask Better Questions

Want to learn more about which application security testing method is best for you? Click here to learn more about DAST and IAST and the questions you should be asking.

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? 

But, before we begin, for those of you new to IAST or DAST, here is a quick 101.

DAST: 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, it can simulate security use cases effectively across the application. Good examples of a DAST tool would be OWASP’s ZAP, BURP Suite, Arachni, etc.

IAST: Interactive application security testing (IAST) uses a concept commonly known 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 behaviour while the application is being used. The agent hooks itself to various functions and calls of the application and identifies security issues as it's able to see inside-out — both from code and flow of traffic into and out of the application.

There are a 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

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. 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 is my answer to the above questions:

One 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 additional hardware. The DAST tool set up a bit simpler. 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 the comprehensive nature of metrics vary from tool to tool and supplier to supplier; therefore, I won’t make a distinction here.

Process

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 a 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 status and DevOps maturity?

Which is more important to you: continuous integration or 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-and-play tool and dependency on tool supplier notwithstanding, it is effortless to integrate into your pipeline, whereas only a few DAST tools even have the capability to be integrated as part of a toolchain. Generally speaking, however, it does take more time to integrate a DAST tool compared to an IAST tool. Something 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 to 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, Continuous 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.

Technology

The first and foremost here is to ensure that the 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 percent 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 that have languages that their library supports. The current IAST tools, collectively, only support a 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 and 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 in the comments below.

ZippyOPS Provide consulting, implementation, and management services on DevOps, DevSecOps, Cloud, Automated Ops, Microservices, Infrastructure, DataOPS, and Security

Services offered by us: https://www.zippyops.com/services

Our Products: https://www.zippyops.com/products

Our Solutions: https://www.zippyops.com/solutions

For Demo, videos check out YouTube Playlist: 

https://www.youtube.com/watch?v=4FYvPooN_Tg&list=PLCJ3JpanNyCfXlHahZhYgJH9-rV6ouPro

If this seems interesting, please email us at [email protected] for a call.

Relevant Blogs: