Which Is Superior? Static or Dynamic AppSec Testing
Hint: The question is irrelevant.
Static and dynamic application security testing, called SAST and DAST respectively, are compared to each other once in while. Both being quite different automated solutions with the same goal, this is understandable. It’s important to understand that these technologies are not replaceable with one another. This is Bedirhan and in this post we will go through a discussion why this is so. Let’s dig in to find out more…
Here’s the key difference between the two technologies; static security testing is executed on applications that are not running, these tools work on the code resting, hence the name static. And dynamic security testing is vice versa, that is the target applications should be running during the security scanning.
First of all, while both technologies are “must haves” for a secure software production and deployment, they also have inherent limitations and therefore use approximations. So, it’s a fact that they both boost the security of a product when utilized correctly and they both take considerably less time compared to their manual counterparts, namely, penetration testing for DAST and security code review for SAST.
But they are not, as no automated security solution is, magic bullets. Please don’t fall into any kind of false sense of security pitfall, in which you find yourself saying “we have such and such tool which spots all of the critical security bugs we have”. They both suffer from false alarms with the relatively comparable false alarms/true alarms ratio.
That’s enough for Security Tool 101. Let’s now try to list distinct strengths of SAST and DAST separately for a later discussion.
Static Application Security Testing
Program Analysis has a nearly five decades of history. The first papers of static code analysis are dated back to 70s. While the techniques are improving and changing, the base is solid and alive. SAST tools stand on the shoulders of both the immensely accumulated and then again of course new research.
Here are some of the distinct strengths of SAST tools;
Software Coverage
Having the code of target application code, static code analysis can find unused, hard to fuzz, end-points, server side hard-coded sensitive data. This leads to better coverage. SAST tools can also flag server-side code quality issues along with the security related ones. Moreover, it can also analyze old versions of server-side third party libraries that can create security .
Shifting Leftest
Since there is no need to run the software for testing, SAST tools can be utilized as soon as the code is being produced, developed that is. So, static security analysis can be applied in the early hours or days of individual sprints without deploying the application on a pre-production, production or developer server. So, we can shift the security more to the left on our software production pipeline.
Developer Familiarity
The results of a SAST tool contains findings with the original code pieces or configuration directive blocks. This is invaluable for a developer to pinpoint any weakness. This way of reporting diminishes the time to find out the problematic code. But more importantly by showing the root cause of the weakness, which is the code piece that contains the dangerous API call which is in static analysis parlance called the sink, SAST directs the developer to a better solution for fixing the bug.
Safe to Execute
It’s always safe to execute a SAST solution against an application, especially on a production ready software. Tests executed on a target application always pose risks of creating extra traffic, noise and perhaps denial of service.
Dynamic Application Security Testing
In parallel with the advance of HTTP based applications, DAST adoption gained acceleration in the early 2Ks. With less security awareness, they were first used mainly by security auditors to spot and exploit server-side weaknesses.
Here’s are some of the distinct strengths of DAST tools;
Vertical Coverage
When applied on a production environment, dynamic scanning not only finds code related weaknesses it can also spot authentication and sensitive data transmission bugs. When a DAST tool is configured for a specific target, such as authentication flow and with multiple credentials, it can scan and locate for critical authorization problems as well.
Non-Existing Code
Since they interact with the dynamic application, DAST tools can also be utilized to find security issues when there’s no source code of a target application is at hand. Dynamic security testing tools don’t require the source code to operate.
Security Auditor Familiarity
DAST solutions reports are more like penetration test reports. The contain exploit related finding details. Since information security professionals are much more akin to hacking techniques than software development (which is gradually changing), dynamic security testing reports are familiar for security auditors to understand and act upon.
Less Technological Dependent
Dynamic solutions are less dependent to specific technologies that is used to produce software. They can talk HTTP and that’s the basis of most of the web and mobile based applications. Having said this, HTTP support is not enough. They also have to support any emerging new web technology, such as web sockets, HTTP/2, various client side SPA libraries or technologies straying from a classic JSON/Form Based HTTP input parameter structure, such as Google Web Toolkit etc.
Onto a Dialectic Discussion
In fact, when one school of bias brings an advantage of using a specific type of solution or disadvantage of using the other, there always seem to be another side of the coin. Here, let’s us list some of the most popular claims made by the solution providers and have a little discussion.
On the technologies they support
Both solutions should support old and new technologies in order to scan targets properly. For example, a SAST solution should support each technology used to implement a target application, such as Java, .NET, Go, Python etc.
On the other hand, a DAST solution also has to comply well with HTTP parameter structures and client side technologies, such as web sockets, hard to count number of JavaScript and CSS libraries, old school JNLP or even slightly more contemporary Silver Light technologies.
For a DAST solution, heavy JavaScript client side interfaces make it hard to crawl and figure out the endpoints that the target applications have. Moreover, desktop and native mobile applications make it nearly impossible for DAST tools to scan a product without manual intervention.
On the other hand, for a SAST solution the quality of scanning is reduced for weak typed languages such as JavaScript and Python than for strongly typed languages such as C# and Java.
What about Microservices?
Since a DAST solution scans an application vertically, it can, as the crawled attack input vectors permit, touch any components on the way. This is especially true for a production environment (which in turn has its own risks to run a DAST solution on a serving target application). A dynamic testing tool, therefore, can scan a microservices architecture where the services are tied together and working.
At first it may seem less likely for a SAST solution to scan different code bases and combine the results. But, this is surely possible. Moreover, since the code of individual services accept input from outside, just like Web APIs, a SAST solution is too able to scan a set of microservices based software projects independent to each other calculating data flows.
What’s with SAST False Alarms?
Because of the enormous scan coverage that a SAST tool has, it produces a huge number of issues on a target code base, including a high rate of True Positives of code quality findings. Therefore, the total number of false alarms is usually also high.
To manage this situation, most of the static code analysis tools contain a set of issue related attributes where consumers can use to prioritize and filter out the noise. That being said, all the issues should be audited by a security code review professional or security-aware developer in order to really squeeze the most out of the SAST solution.
On the other side of the coin, the DAST solutions, too, have and bound to produce false or irrelevant alarms but their false alarms ratio are aligned with the total number of issues they produce.
Another advantage that a DAST solution has is the ability to actually exploit an issue to make it a True Positive. However, that may not be an easy task for a complicated application for example with binary outputs or hard to bypass blacklist filters automatically.
On CI/CD integration
Both DAST and SAST tools have APIs and/or command line support. So, both of the technologies can be carefully placed into CI/CD pipelines and triggered with events like git push or merge, etc.
Tool configuration
A SAST tool nearly requires zero configuration for scanning, as with a DAST tool.
However, it may become important to configure a DAST tool for correct authentication and crawling to populate attack input vectors. Whereas, a SAST tool should also be customized with defining custom validation APIs in order to produce relatively noise free issues.
A Sense Conclusion
Both DAST and SAST technologies have inherent limitations, however, tool producers are always on the look out for improvements. Both of the tools play incredibly well with the automation, speed and integration they provide.
Dynamic and static application security testing solutions find similar and highly critical security weaknesses on the target applications. However, apart from these low hanging fruits or gray rhinos, whichever you prefer, the best way of getting the maximum is through manual analysis of the results they produce.
Producing a secure product has more than one facets. So, you need every quality tool that are complementing each other on a lot of venues. It’s not wise to choose one solution over another, simply because marketing mumbo-jumbos say so.
