Bugs and weaknesses in software are common: 84 percent of software breaches exploit vulnerabilities at the application layer. The prevalence of software-related problems is a key motivation for using application security testing (AST) tools. With a growing number of application security testing tools available, it can be confusing for information technology (IT) leaders, developers, and engineers to know which tools address which issues. This blog post, the first in a series on application security testing tools, will help to navigate the sea of offerings by categorizing the different types of AST tools available and providing guidance on how and when to use each class of tool.
See the second post in this series, Decision-Making Factors for Selecting Application Security Testing Tools.

Application security is not a simple binary choice, whereby you either have security or you don't. Application security is more of a sliding scale where providing additional security layers helps reduce the risk of an incident, hopefully to an acceptable level of risk for the organization. Thus, application-security testing reduces risk in applications, but cannot completely eliminate it. Steps can be taken, however, to remove those risks that are easiest to remove and to harden the software in use.
The major motivation for using AST tools is that manual code reviews and traditional test plans are time consuming, and new vulnerabilities are continually being introduced or discovered. In many domains, there are regulatory and compliance directives that mandate the use of AST tools. Moreover--and perhaps most importantly--individuals and groups intent on compromising systems use tools too, and those charged with protecting those systems must keep pace with their adversaries.

There are many benefits to using AST tools, which increase the speed, efficiency, and coverage paths for testing applications. The tests they conduct are repeatable and scale well--once a test case is developed in a tool, it can be executed against many lines of code with little incremental cost. AST tools are effective at finding known vulnerabilities, issues, and weaknesses, and they enable users to triage and classify their findings. They can also be used in the remediation workflow, particularly in verification, and they can be used to correlate and identify trends and patterns.

Guide to Application Security Testing Tools
This graphic depicts classes or categories of application security testing tools. The boundaries are blurred at times, as particular products can perform elements of multiple categories, but these are roughly the classes of tools within this domain. There is a rough hierarchy in that the tools at the bottom of the pyramid are foundational and as proficiency is gained with them, organizations may look to use some of the more progressive methods higher in the pyramid.

Static Application Security Testing (SAST)
SAST tools can be thought of as white-hat or white-box testing, where the tester knows information about the system or software being tested, including an architecture diagram, access to source code, etc. SAST tools examine source code (at rest) to detect and report weaknesses that can lead to security vulnerabilities.
Source-code analyzers can run on non-compiled code to check for defects such as numerical errors, input validation, race conditions, path traversals, pointers and references, and more. Binary and byte-code analyzers do the same on built and compiled code. Some tools run on source code only, some on compiled code only, and some on both.

Dynamic Application Security Testing (DAST)
In contrast to SAST tools, DAST tools can be thought of as black-hat or black-box testing, where the tester has no prior knowledge of the system. They detect conditions that indicate a security vulnerability in an application in its running state. DAST tools run on operating code to detect issues with interfaces, requests, responses, scripting (i.e. JavaScript), data injection, sessions, authentication, and more.
DAST tools employ fuzzing: throwing known invalid and unexpected test cases at an application, often in large volume.