Micro Focus is now part of OpenText. Learn more >

You are here

You are here

SAST, DAST, IAST, and RASP: Pros, cons and how to choose

Rob Lemos Writer and analyst

Any company developing software, whether as a product, a service, or for internal use, should focus on software security, but there is no perfect way to embark on developing, or improving, a secure development lifecycle.

Some organizations need to focus on their developers, adding static application security testing (SAST) to the development cycle to catch potential flaws early. Other organizations may want to prove their need by using dynamic application security testing (DAST) or penetration testing to show how vulnerable their applications are. 

Then there's interactive application security testing (IAST), which uses agents and additional software libraries to collect data from running applications that can then reveal vulnerabilities. Companies that want to “virtually patch” their applications can lock down their portfolios using some form of application firewall or a newer technology, such as runtime application self-protection (RASP), a form of IAST.

Not sure which is for you? Here are the benefits and potential drawbacks of each.

1. Static application security testing: Eliminate vulnerabilities early

SAST tools, which scan source code to find known patterns of vulnerabilities, are at the forefront of secure code development tends. The tools are increasingly provided to developers as the first step in weeding out the most obvious vulnerabilities from their code.

SAST tools have a bad reputation for producing too many alerts for minor software flaws and unexploitable defects, and for finding only narrow classes of bugs. Nonetheless, the tools are an important part of any secure development lifecycle because they can be integrated into the development environment, preventing developers from making fundamental security errors that could produce vulnerabilities and teaching them to avoid making similar mistakes in the future.

Eliminating vulnerabilities during development saves money. Estimates range from a low of 20% up to a high of 100%, if a defect is caught at the initial design level. “The cheapest place to find bugs is early in the secure development lifecycle,” says Daniel Kennedy, research director for information security at 451 Group.

Integrate automated code checking into development cycle

Consider how well a SAST tool integrates into your company’s existing development environments. Most tools support the major web languages, Java and .Net. Static tools generally also support some form of C, C++, or C#.

In addition to supporting the language that your development team uses, the tools should seamlessly plug into the most common integrated development environments (IDEs).

“The developer is extremely busy,” says IBM vice president Ravi Srinivasan, who is responsible for network security offerings. “They don’t want to have to go to a separate program to run application security testing.”

SAST: It's not just about catching bugs

The developer is a SAST system’s most common user. The best tools provide feedback to teach developers how to use secure software patterns and avoid code libraries deemed too insecure or infrequently patched, and they explain how to repair potential vulnerabilities.

Providing developers with simple-to-use static analysis tools that can check code quickly and provide easy-to-understand feedback pays dividends down the road. Aetna, for example, found that developers using static analysis tools learned to produce more secure code.

“The defect density drops significantly when developers use static analysis tools,” Aetna’s Routh says. “They are learning how to avoid defects on their next project, and it is the most valuable tool in teaching developers secure coding practices.”

Strike a balance between SAST false positives and developer goodwill

Today’s application security testing tools are getting more comprehensive, but they still require developers and security professionals to weed out false positives. In some way, the greater depth of testing presents its own problems, says Denim Group’s Dan Cornell.

“A lot of static vendors were trying to get the most results, but what people realize now is that there is a tax that comes along with all the stuff you found,” he says. “So finding more stuff is not necessarily good. If I find too much stuff, I have to wade around in all the results to find what is really important.”

The issue can be critical for companies focused on an agile or DevOps model. They may find that static analysis tools take too long to run to be used in daily development. “The longer it takes to run, the more difficult it is and the longer it takes security people to weed out the false positives and the less integrate-able it is with the development cycle,” Aetna’s Routh says.

2. Dynamic application security testing: Find exploitable vulnerabilities

You can take a more strategic approach to testing by using DAST.
Also known as “black-box testing,” dynamic analysis tests for different types of vulnerabilities in running applications.

The choice between adopting static or dynamic analysis tools first depends on your organization's situation. Static analysis tools give developers feedback and educate at the same time. Dynamic analysis tools can give security teams a quick win by immediately finding exploitable vulnerabilities.

In most cases, you should run both. Static and dynamic analysis tools plug into the development process in different places. Run static tools  as often as is practical and give the feedback directly to the developer. That allows managers and the security team to monitor developers' progress in eliminating bugs. DAST should be used less often, and only by dedicated security and quality assurance professionals.

While DAST is suited to a waterfall development approach, agile and DevOps development can benefit as well. “Dynamic scanning is something that you apply after you have a runtime version of the software,” Routh says. Dynamic scanning is typically done by the QA teams. In a Scrum team, there may be a designated QA team that is part of each sprint, but they are not the developers.

Use dynamic analysis to help find assets

Your first step is to make sure you know which applications are running on your network. Companies that embark on a new application security initiative can tie network scanning into the DAST process. Doing so requires first searching the network for applications and testing those applications for vulnerabilities. This process can help security teams stay on top of unknown and rogue applications, says Frank Catucci, application security manager for Qualys, a network and application security firm.

“A lot of customers who come to us say they know what they need for application security, but they have so much that is out there running, there may be web services that they are not aware of,” he says.

By asking a few simple questions, you can better understand your software security status quo. Security groups should first figure out how many web applications they have running "Most companies do not know what they own, and that is a major issue,” says Jeremiah Grossman, the Chief of Security Strategy at SentinelOne. “Down the road, when they get hacked, when they get compromised, it is almost always because of a vulnerability in a website they did not know about.”

Build DAST into the quality assurance phase

While static code analysis can find bad patterns in code and teach developers more secure coding techniques, DAST is about catching exploitable vulnerabilities before they get into a production environment. Development groups and security teams should build a dynamic testing phase into the pre-release QA phase of any secure development lifecycle.

The goal is not to find every vulnerability, but to find the most exploitable issues. “You don’t want a mess of vulnerabilities in production, so you use SAST to rid yourself of those as much as you can,” Grossman says. “But not all vulnerabilities are available to attackers; there are a lot of vulnerabilities that do not pose a threat. That is what DAST is for—finding vulnerabilities relative to the bad guys, where there are no more rules.”

Shorten testing and remediation time

Testing takes time, and making sense of the results of that testing can take even more time. While false positives are less of an issue for DAST, security teams and developers should focus on evaluating each product’s ability to quickly test for a required set of potential vulnerabilities, and produce reports that succinctly tell developers how to fix the problems.

Time becomes an even bigger issue for development groups focused on a DevOps model of software development and deployment. Such groups have to automate more and push the testing to earlier in the process, making time a critical factor, says Adrian Lane, chief technology officer for security consultancy Securosis.

“It changes the way we test, and it forces companies to build a lot of their own infrastructure,” he says. “So a big question is whether you can use an API to script and automate the testing, not just integrate with the developer systems.”

3. IAST, including RASP: Protect code against exploits and known bugs

While static code analysis arrived about two decades ago and dynamic analysis has become popular over the last decade, a new approach—known as interactive application security testing (IAST), or “glass-box” testing—promises to catch attacks that the other approaches miss. IAST runs as an agent, allowing you to collect and analyze event data from running applications.

Jeff Williams, chief technology officer of Contrast Security and a pioneer of the approach, argues that both static and dynamic analysis fail to catch many types of vulnerabilities that affect applications. IAST can help to better secure the software, he says.

“Bottom line for me is that dynamic and static tools have been around for over a decade without improving and are not likely to improve,” he says. “It’s a huge problem that prevents doing application security at scale and leaves us all vulnerable.”

The promise of software agents

The key to interactive analysis is turning the application into a tool that also works for security. Either by installing software agents on an application server or by instrumenting the application at development time, interactive analysis techniques allow the collection of data on application and security events.

The data can detect software flaws that other techniques would miss. In addition, combining agent-based instrumentation of applications with code analysis and dynamic scanning can help reduce false positives and give developers a better idea of where vulnerabilities exist in their code.

“I’ve always disliked the idea that security makes things less efficient,” Contrast’s Williams says. “Security is an enabler. Done right, application security technology speeds software development and operations by providing continuous, accurate, useful information in real time and at scale.”

Got legacy apps? Protect them with RASP

The same agents and libraries you use to detect the signs of vulnerabilities in programs can also block bad behavior—a likely sign of an attack. The use of runtime application self-protection (RASP) technology can prevent attacks and deliver immediate benefits to companies. For security teams that need to protect applications that may not be actively developed, an application firewall or RASP agent may work well. Think of RASP as a specific type of IAST.

“RASP sits inside applications and can monitor and block vulnerabilities,” says Maria Bledsoe, a senior manager with HP Enterprise’s security products group. “RASP is a compensating control.”

Pilot an IAST program

Because IAST is a relatively new technology, companies should pilot a tool to determine if it’s right for their development programs. More mature security teams are already piloting IAST efforts. 

“We see it as something that we are definitely doing,” says Aetna's Routh. “So we are going through a process of evaluating the products. The tools are relatively immature, but they are promising.”

SAST, DAST, IAST: Make the right choices

There is a role for all three technologies: static, dynamic, and interactive analysis.

While static analysis aims to help developers produce better and more secure code, dynamic analysis heads off exploitable vulnerabilities before they are released. IAST instruments an application so that information about potential malicious activity can be gathered while the software is running. And some IAST systems also block the attack, which is a function of the RASP technique.

In the end, how a you proceed in adopting application security testing tools depends on how mature your efforts are in creating a secure development lifecycle, what type of software you have under development, and the resources your organization can dedicate to the effort.

In implementing security development lifecycles at six different organizations, NCR’s enterprise security architect Nir Valtman learned that progress is what’s most important.

“Whether you have SAST or DAST or IAST, it doesn’t matter how many bugs you have at the moment,” he says. “The only thing that matters is the trending chart—reducing the number of bugs that you have.”

Additional resources

To dive deeper into the pros and cons of various security testing types, consider these articles:

Keep learning

Read more articles about: SecurityApplication Security