Both static application security testing (SAST) and dynamic application security testing (DAST) share a common goal of finding security vulnerabilities in an application. However, the perspectives and techniques used by SAST and DAST tools are very different.

DAST tools use an outside-in approach to test an application at runtime, to detect the attack surface and probe it for potential vulnerabilities. As a result, DAST tools, and specifically their vulnerability findings, have little information on the internal structure of the application despite what it learns about the application’s runtime response behavior.

SAST tools, on the other hand, use an inside-out approach: scanning an application’s source code for potential programming flaws that have the potential for exploitation if exposed as part of the attack surface. By definition, SAST tools will have little insight into the runtime behavior of the application.

 

DAST (Black box testing)

SAST (White box testing)

Performed later in Software Development Lifecycle (SDLC_, once the application is in a deployable state. Performed throughout the SDLC before the application is deployable
Outside-in—hacker’s perspective Inside-out—developers perspective
Detects vulnerabilities by conducting attacks against a running instance of the application; typically only web-applications Detects potential vulnerabilities by identifying insecure code paths without actually executing the program; supporting both web and desktop applications
Only test program paths that are actually executed Full code coverage, even code that is never executed
Typically finds less than SAST, but findings are more precise Reveals a wider range of findings, but many are not exploitable (imprecise). Prioritization is difficult

This table shows the complementary nature of DAST and SAST techniques for risk assessment. There is a lot of value to running both types of tools on a code base. However, the results provided by the tools offer little in the way of effective correlation, forcing most SAST and DAST users to analyze the results separately, as independent assessment activities.

Hybrid Analysis Mapping (HAM), also called Hybrid Application Security Testing (HAST), correlates the results of SAST and DAST tools so that the user can see which of the source code weaknesses are actually exploitable from the perspective of an external attacker. However, correlating the results of multiple SAST and DAST tools is not easy. DAST tools report findings detected for URLs, while SAST tools report findings detected in source code files. Identifying the set of source code files that correspond to a URL can be extremely difficult. Each web framework uses its own approach to structuring its source code elements, which forces a one-to-one mapping approach per web framework.

Secure Decisions has been funded by the US Department of Homeland Security (DHS) Science and Technology (S&T) Directorate (Contract # D14PC00060) to develop a new, more efficient method of conducting HAM that overcomes many of the existing hurdles. The results of this DHS-funded project, entitled Code Ray: Software Assurance Risk Management Framework for Hybrid Analysis Mapping, are being transitioned into new releases of Code Dx Enterprise.

The HAM solution to be incorporated into Code Dx overcomes several of the known challenges. DAST to SAST cross-mapping has previously been an inefficient process yielding incomplete results. Some solutions rely solely on trying to map source code to URLs. Others are point solutions that only work within a single vendor’s tool suite, without incorporating the results of multiple SAST and DAST tools. In addition to these drawbacks, DAST to SAST correlation is hindered by the fact that many AppSec tools, especially open-source, don’t conform to security standards such as Common Weakness Enumeration (CWE) or Software Fault Patterns (SFP).  This limits the ability to cross-map the output of DAST and SAST using security standards as a common denominator.

The HAM solution under development by Secure Decisions, and being transitioned into Code Dx, correlates results from a variety of open-source and commercial DAST and SAST tools, using techniques beyond just CWE and SFP to produce a set of merged findings. It is designed to improve the analysis speed, accuracy and confidence in detection of vulnerabilities by cross-mapping and normalizing the output of hybrid techniques.

Version 2.0 of Code Dx completed a critical step in the HAM process: adding support for consuming and de-duplicating the results of DAST tools. In fact, we can now consume the results of the following DAST tools: IBM AppScan, HP WebInspect, Veracode, Acunetix, Netsparker, Burp Suite, OWASP ZAP and Arachni. Support for other tools will come in future versions of Code Dx Enterprise.

Next on our list is to instrument an application under test using Interactive Application Security Testing (IAST) techniques to provide code level details to DAST findings. This will allow us to automatically correlate the SAST and DAST results to show the attack surface of the code; that is, what parts of the code are accessible to a potential attacker using dynamic penetration tools.

Stay tuned for the complete incorporation of HAM into Code Dx Enterprise in 2017.