Innovation needs speed. Continuous integration, continuous delivery, and continuously rising demand for development velocity - for developers, they all translate into continuous labor. Under such conditions, it’s no wonder some corners are rounded, if not cut altogether. Application security is one such corner.

The gap between security teams, developers, and the goals set by the C-suite often lead to security being an afterthought in the application delivery chain. But priorities are clearly shifting: 52% organizations plan to increase their IT spending in 2023, focusing strongly on cybersecurity. And the even better news is: with proper security testing in place, you don’t have to slow down delivery. 

Two of the most common testing technologies used in the CI/CD pipeline to keep rogue code and vulnerabilities out of applications are Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST). In this article, we’ll review and compare both types of application security testing.

Spoiler alert! After reading this post, you likely won’t have to choose between SAST and DAST.

What is Static Application Security Testing (SAST)?

Static application security testing (SAST) is a white-box automated testing technique that scans and analyzes application source code and related dependencies (frameworks and libraries) for various security vulnerabilities. These vulnerabilities include (but are not limited to) XSS-based attacks, SQL injections, buffer overflows, keys and passwords embedded in the source code, XML external entity (XXE) attacks, and other OWASP Top 10 security risks.

SAST tools are automated and set to run early in the CI/CD pipeline, executed whenever code is committed to a source code repository (usually Git). They provide immediate and clear insights on potential vulnerabilities that may have been introduced into the code along the development process. 

Since SAST is employed early in the SDLC to detect vulnerabilities and coding errors before applications are compiled, it’s considered one of the most widely adopted testing methodologies in development teams shifting left security and implementing DevSecOps principles.

Pros of SAST

• No need to run the application or even have a running application. You can run SAST on your code and check it for vulnerabilities without building the application or even having a fully functional app.
• Instant feedback. SAST tools quickly scan and analyze your code, providing near-real-time input and insights into the flaws detected.
• Easy integration and automatic execution. Most SAST scanners integrate seamlessly with popular CI/CD tools and run automatically against reliable and accurate vulnerability databases. All without interrupting or slowing developer workflows.
• Find early, fix early. SAST is performed early in the SSDLC - as early as pre-commit - enabling the developers to apply fixes before the code is compiled and shipped. This allows for proactive mitigation of security vulnerabilities and misconfigurations in your application’s code.

Cons of SAST

• “Low-hanging fruit.” Since static code scanning employs predefined security rules to find publicly known vulnerabilities, it is only partially effective in protecting against business logic vulnerabilities or those introduced by dynamic dependencies. It does not effectively protect your applications against supply chain attacks, third-party service misconfigurations, and runtime vulnerabilities.
• False positives. The main drawback of SAST is that it tends to produce many false positives. This has created a kind of “The SAST that cried CVE” situation, in which developers release vulnerable applications because they treat most issues detected as false positives and irrelevant - and they usually are. Until they aren’t.

Common SAST tools

• Bandit -  a tool designed to find common security issues in Python code.
• OWASP ASST -  an open-source, source code scanning tool. 
• Semgrep - a lightweight polyglot static analysis tool that finds bug variants with patterns that look like source code.

What is Dynamic Application Security Testing (DAST)?

To make it really simple, Dynamic application security testing (DAST) is the opposite of SAST. A black-box technique, DAST entails testing the behavior of running applications from the point of view of an attacker. Also called behavioral testing or “fuzzing,” DAST tools can help developers discover potential vulnerabilities to malicious attacks beyond the source code. 

DAST tools scan more of an application's cyber attack surface, including API endpoints, web services, and elements of the application's cloud infrastructure or host system that may be susceptible to compromise.

DAST tools test the application against vulnerability sources like the OWASP Top 10 or SANS/CWE 25 to uncover runtime vulnerabilities before the application is pushed to production. Implemented later in the CI/CD pipeline build phase, DAST requires some interaction from the tester to preconfigure testing parameters before the tests can be executed automatically.

Pros of DAST

• Lower rate of false positives. With DAST implemented later in the build phase, the testing is conducted against the actual application and its environment in runtime, allowing it to catch actual (rather than potential) vulnerabilities. 
• Polyglot by design & no access to the code. DAST does not require the tester to be familiar with the programming languages used in developing the application, nor does the testing require accessing the application's code. The same applies to DAST tools - they work transparently with any framework, making DAST a more robust testing methodology than SAST.
• Applicable to a broader area of the application’s attack surface. While SAST is limited to your codebase and dependencies, DAST can scan your IT infrastructure for misconfigurations, test API or web services, and run different attack scenarios.

Cons of DAST

• Cannot point to the exact source of the vulnerability in the code. Since DAST scanners cannot access the application’s code, they cannot point developers to the specific section or line in the code that’s causing the potential vulnerability. That means more manual work is required to pinpoint and resolve issues detected in the dynamic application scan.
• Attack surface blindspots. DAST tools can scan for a wide range of vulnerabilities within the application code but fail at seeking out potential vulnerabilities in parts of the application stack that are not executed. 
• Time and resource-consuming. Traditionally, DAST tools require a specific skill set to configure and execute effectively. Moreover, the time it takes to run DAST scans, both in terms of CI/CD minutes and waiting for an app to pass the tests, can be significant - as long as several days for sufficiently complex applications and multiple testing scripts.

Common DAST tools

• OWASP ZAP by OWASP - The OWASP Zed Attack Proxy (ZAP) is one of the world’s most popular free security tools and is actively maintained by a dedicated international team of volunteers.
• OSV-scanner by Google finds existing vulnerabilities affecting your project’s dependencies using the data provided by osv.dev.
• Legitify by Legit Labs detects and remediates misconfigurations and security risks across all your GitHub and GitLab assets.

SAST vs. DAST: which should you use?

If you’ve read this far, you probably understand the spoiler in the introduction. To build a robust and scalable application security testing strategy, you must employ both SAST and DAST in your pipeline. In fact, you’ll probably need SCA (software composition analysis) and IAST (interactive application security testing), depending on your application, its life stage, and its intended end-users. It’s not really a question of which you should employ, but rather the question of when you should use SAST or DAST in your SDLC.

Orchestrating application security testing with Jit

Some of the main challenges with DAST and SAST are configuring and maintaining them as your application and its potential vulnerabilities scale and grow. With Jit, you get a complete Minimal Viable Security package that covers precisely what you need and doesn't waste resources on things you don’t. Jit integrates with powerful DAST and SAST tools, some of which are mentioned in this article, such as Semgrep, Bandit, Legitify, and OVS-scanner, to deliver a complete DevSecOps toolchain across IDE-Code-Pipeline-Cloud and Runtime.

Start free today and discover how Jit can streamline your DevSecOps processes and enable your developers to effortlessly dot the i’s and cross the t’s of modern application security.

‍