I wrote a short summary of the difference between SAST and DAST tools for some of my peers and thought It would make for a good short blog.
SAST and DAST are different testing approaches with different benefits. They find different types of vulnerabilities, and they’re most effective in different phases of the Software Development Life Cycle (SDLC). SAST should be performed early and often against all files containing source code. DAST should be performed on a running application in an environment similar to production.
SAST and DAST are application security testing methodologies used to find security vulnerabilities that can make an application susceptible to attack. Static application security testing (SAST) is a white box method of testing. It examines the code to find software flaws and weaknesses such as SQL injection and others listed in the OWASP Top 10. Dynamic application security testing (DAST) is a black box testing method that examines an application as it’s running to find vulnerabilities that an attacker could exploit.
SAST white box security testing
- The tester has access to the underlying framework, design, and implementation
- The application is tested from the inside out
- This type of testing represents the developer approach and is best performed when there are specific coding standards to test against
- It requires access to source code
- SAST does not require a deployed application
- It analyzes the source code or binary without executing the application
- It finds vulnerabilities early in the SDLC as a scan can be executed as soon as code is ready to be scanned
- Because code can be scanned at check-in, fixes can be addressed earlier in the SDLC for less expense
- Findings can often be found before code enters the QA cycle
DAST black box security testing
- The tester has no knowledge of the technologies or frameworks that the application is built on
- The application is tested from the outside in
- This type of testing represents the hacker approach
- DAST does not require access to source code or binaries
- It requires a running application because it analyzes by executing the application
- Vulnerabilities are found towards the end of the SDLC and are typically found after the development cycle is complete
- Since vulnerabilities are found toward the end of the SDLC, remediation often gets pushed into the next cycle
- Critical vulnerabilities may be fixed as an emergency release
- Since DAST uses dynamic analysis on an application, it is able to find run-time vulnerabilities which can include environment-related issues
- DAST is most typically used to scan applications like web applications and web services
- Because DAST is typically offered as a cloud-based tool FedRamp/TxRamp certification may be required for governmental entities
The following Heat Map compares some of the major SAST and DAST Features.
It is important to gather information on the potential user base to understand the users software development environment, Software Development Lifecycle (SDLC), programming languages used and coding standards/polices. These will help determine the best approach to use for tool implementation.
Neither SAST or DAST really addresses shadow code detection and removal. Shadow code is best addressed during the SDLC by verifying the valid code during development and signing the code with a hash. This requires mature release and change management processes as well as a source and mechanism for signing certificates.