Dynamic analysis security testing (DAST) works like a hacker-in-a-box, so to speak, by exploring and testing web applications and services via HTTP and HTTPS. DAST is one of the oldest automated application security testing (AST) techniques, tracing its roots to the mid-1990s. Since it interacts with live web applications and web services and automates hacker activity, it has always been popular with penetration testers and security auditors looking to save valuable time.

DAST Today

There are numerous free, low-cost and premium commercial offerings in the DAST space. While IBM has been a market leader in this space since it acquired of Watchfire in 2007, this application of DAST is well understood. There is, however, another application that was rarely adopted in the past, but began to change in 2015 and dramatically shifted last year.

I’m talking about making DAST a part of the software development life cycle (SDLC). Organizations want to implement AST into the SDLC because the sooner a security or functional defect is discovered, the cheaper it is to fix. In fact, according to the Rice Consulting report, “STBC: The Economics of Testing,” a defect can cost 100 times more to fix if not detected by the time the application reaches production.

The number described above does not even take into account potential damage that can result from a security issue being live in production. While the exact cost difference will likely vary, it’s always much easier, faster and cheaper for a developer to find and fix a relatively new defect than one that is weeks or months old.

This holds true for all issues and defects, not just security-related ones, and led to an ever-increasing focus in areas of continuous integration (automated builds) and continuous integration (automated testing and deployment). But I’m getting a bit ahead of myself. First, let’s take a quick look at the established norms of AST within the SDLC.

Start Your Free Trial of IBM Application Security on Cloud

Deploying Application Security Testing Within the SDLC

Organizations typically deploy one of two mainstream AST techniques: DAST and static application security testing (SAST).

As we discussed, DAST works by sending mock attacks to web applications and services via HTTP/HTTPS, just like a cybercriminal would. DAST requires little knowledge of an application’s inner workings, and findings inherently provide a proof of exploit that demonstrates whether an application is indeed vulnerable and how that vulnerability can be exploited. Its biggest strength goes hand in hand with its biggest challenge: It requires a web app or service that’s running and functioning, usually in a test environment.

SAST, on the other hand, examines application code directly. It usually works by finding methods that bring data into the application (sources) and then following that data through other method calls in the code until it arrives at a sensitive method (a Sink) without detecting proper sanitization or validation in the overall data flow. SAST does not require an application to run, and it provides a deep and comprehensive view of an application’s inner workings.

Historically, few organizations could integrate DAST into the SDLC because software development cycles were largely based on the Waterfall model, in which applications were written over periods of months or years. Applications were in pieces during all that time. Intense integration efforts usually took place right before application testing began. This meant that there was no running application until the 11th hour, which prevented developers from conducting DAST early enough.

Unlike DAST, SAST does not require the application to be running — in fact, it may not even need to compile. SAST analyzes application code directly by looking at what developers wrote instead of the web interface produced by the application. This seemingly provides a better match for the needs of those developers. It’s no surprise, then, that only a few companies, primarily those on the bleeding edge of software development practices, could even consider implementing DAST in the SDLC. SAST was the one and only hope of AST in the SDLC for most organizations. I started working with SAST in 2008, and I still clearly remember the mix of hope, hype and excitement in every customer engagement.

DAST Versus SAST

Imagine you’re looking for a new car. You go to a dealership and ask to test drive one. You turn the key in the ignition and it starts. You put it in gear and hit the gas. The car moves forward. You hit the brakes, and nothing happens. You don’t know if the problem originates with the brake pedal, cylinder, fluid or calipers, but you know you have a big problem. That’s DAST — you’ve tested the brake system end to end and it failed.

SAST would be more akin to dismantling the car and referencing its specifications to determine whether a part is within its operational tolerances and parameters or needs to be repaired or replaced. SAST is a lot more thorough but can sometimes overwhelm new users.

The Case for DAST

I’ve realized that DAST offers a better starting point than SAST for organizations new to the secure SDLC, where AST is integrated into the software development process itself. In other words, organizations without an established application security program.

Here are three key reasons why:

1. DAST Findings Are Mapped Directly to Risk

Most successful AST programs are based on mitigating risk. It is widely held that Risk = Impact x Probability. For DAST, the probability is typically rated High or Very High, since the automated hacker-in-a-box tool exposed the vulnerability through a convenient web interface. Impact is defined as the finding’s severity combined with business-driven parameters for the application, such as whether it is customer-facing, revenue-generating, subject to compliance requirements, etc.

For organizations that are new to AST, developers can justify the need for testing by conducting DAST scans on the most valuable applications and identifying a few high-severity issues. It also permits them to tackle the highest-risk issues in the organization’s application portfolio and quickly demonstrate success. Plus, since SAST looks at coding errors rather than actual exploits, mapping SAST findings to actual risk is a lot more difficult.

2. DAST Focuses on Real-World Issues

Modern applications consist of multiple components and systems built by multiple teams and often multiple companies. Since DAST actually exercises applications and services using their web interfaces, it tests the end result of all of these components and systems interacting with each other and highlights real-world vulnerabilities without the need for much insight into each component. SAST, on the other hand, is typically used to examine each component individually. It looks for poorly written code without assessing how different components interact with each other.

3. Developers Buy Into DAST Findings

Since DAST works like a hacker, it essentially demonstrates the problem and provides a proof of exploit for every finding. This allows developers to understand the importance of each finding and provides the context they need to prove or disprove results. Meanwhile, SAST focuses on how well the code is written from a security standpoint. Unless the organization has a very clear mandate and an actionable set of secure coding guidelines, it can be difficult for an individual developer to understand the impact of a SAST finding and decide whether to address it.

Both testing approaches have their inherent benefits, but for an organization building a new application security program, a focus on real-world issues can offer a quicker path to success.

Agile and DevOps

Although DAST has historically been difficult to integrate into the SDLC, that has changed over the past few years. Developers struggled to integrate DAST into Waterfall software development processes, which lasted for months or years, but modern software development has largely moved far beyond Waterfall.

Most organizations have adopted Agile software development, where software development cycles are shortened from months or years to just a few weeks. Many organizations have moved toward a DevOps model, which focuses on continuous integration and delivery, essentially reducing software development cycles to mere hours. This means that web applications and services can be functional in test environments mere hours or even minutes after a new software development cycle begins. Not only does this enable developers to integrate DAST very early in the software development life cycle, but it also permits them to fully automate the process. In fact, IBM Security AppScan Enterprise DAST SDLC integration and scan automation are now very similar to IBM Security AppScan Source SAST integration and scan automation.

What’s more, IBM AppScan Enterprise can act as an HTTP/HTTPS proxy to listen in on functional testing performed by a quality assurance (QA) specialist or automated functional testing tool, such as Selenium, and then utilize that information in a DAST scan. All the QA specialist or testing tool has to do is adjust the HTTP proxy settings to point toward IBM Security AppScan. This allows IBM Security AppScan to learn how to interact with the target web application or service and correctly fill out forms with specialized information, such as driver’s license numbers, employee IDs, case numbers and more. This leads to improved scan coverage and quality and requires virtually no extra work for anyone involved.

If functional testing is automated, as is often the case with DevOps teams, high-quality DAST scans can be fully automated and performed without any human intervention. If functional testing is not fully automated, DAST scans can still be automated with the use of functional test data from the previous manual QA cycle, with good results. That said, the more automated the functional testing, the more easily developers can fully automate DAST.

With the functional test traffic captured, AppScan Enterprise can then perform either a very pointed DAST scan, focused on a particular set of functional test cases, or a complete scan to get the best coverage possible. The former is great for DevOps environments where quick scans focused on recent code changes are key. The latter is great for nightly or weekly scans to catch anything that might have been missed, all with minimal to no overhead for any humans involved. This holds true for IBM’s Application Security on Cloud DAST and SAST offerings as well.

Identifying the Best Starting Point

Today, each organization must determine whether its primary concern is identifying and addressing the highest risk application vulnerabilities or establishing a secure coding culture and enforcing best practices.

Ideally, of course, an organization would address both concerns. Most organizations can gain very tangible benefits by implementing both DAST and SAST to support their application security programs. That said, your primary concern will help identify the best starting point.

DAST will help developers quickly find and address the riskiest issues, improve secure coding practices over time and build a business case for application security testing. SAST is often a more strategic effort that will help enforce secure coding best practices and, eventually, mitigate risk that exists in applications as code quality improves.

Your primary concern is key to selecting the best initial approach since DAST and SAST are very similar in many other ways. Over the last couple of years, I’ve seen more organizations begin to actively adopt DAST into their SDLC processes, automate DAST scans and, most importantly, quickly demonstrate value of AST to their internal stakeholders.

Start Your Free Trial of IBM Application Security on Cloud