How to tune out AppSec noise through DAST

Application security testing can create a huge number of false-positive alerts, but is there a way for development teams to avoid these distractions? There are indeed methods for making the process of testing applications less "noisy" without compromising security.

Modern approaches to dynamic application security testing (DAST) have made significant improvements over the first generation of DAST tools, as well as over the static application security testing (SAST) tools still in use. In this breakdown, we’ll be covering areas of weakness in SAST and in older DAST tools — and how newer solutions can separate the signal from the noise in application security testing.

Problems with SAST

SAST tools scan code for known vulnerabilities and suspicious errors, then generate reports. The process is very thorough but has its drawbacks. Every coding language an organization uses requires a different SAST tool. Furthermore, SAST tools are not able to catch execution errors while an app is running.

SAST tools can also generate an astronomical number of false positives — flagged potential vulnerabilities that turn out to be nothing. A development team might spend an enormous amount of time investigating potential red-flag alerts from SAST tools while runtime vulnerabilities go unaccounted for. It's a tremendously inefficient workflow.

"SAST tools, in particular, have a reputation for flooding developers with security issues that, while technically accurate, are irrelevant in a specific context," wrote Invicti's Zbigniew Banach in a 2022 blog post. "This requires tedious fine-tuning to prevent developers from being flooded with false positive reports."

First-gen DAST solves some but not all SAST problems

DAST doesn't scan code or need to know in which coding language an app is written. Instead, it monitors data traffic in and out of the app while the app is running, flagging alerts when it sees something suspicious.

First-generation DAST tools — or "legacy DAST" tools — work by catching flaws that aren't apparent in static code and only manifest themselves when the app is running. DAST tools use penetration-testing techniques to “poke at” an app and find its weak points.

Legacy DAST tends to be used toward the end of the development cycle, which forces development teams to backtrack if a serious flaw is found deeply embedded in the code. DAST tools often must be triggered manually instead of being set to run automatically.

These first-gen tools are known for their "black box" approach in app testing: A DAST tool can tell that a vulnerability may exist but cannot provide proof that the vulnerability can be exploited. Nor does it assist with remediation. Instead, a developer or app tester will need to manually inspect the flagged vulnerability.

As you might expect, legacy DAST also generates a lot of false positives. These may be too many for a development team to handle. In a 2022 survey of 500 DevSecOps professionals commissioned by Invicti, 94% of respondents said they had found false positives in vulnerability reports, while 67% said they found false positives "all of the time" or "often."

How false positives during app testing create extra work. Credit: Invicti

More significantly, 68% of respondents said they ignored potential vulnerabilities flagged during testing at least once a week, while 97% said that at least once a month, they dismissed false positives that later turned out to be real vulnerabilities.

This highlights a real problem: The volume of false positives generated by SAST and legacy DAST tools could undermine app security testing altogether.

"As developers and testers lose confidence in a vulnerability scanner that generates mostly false alarms, they might start routinely ignoring whole classes of issues from this tool," said a recent Invicti white paper. "Sooner or later, someone will start ticking boxes just to make the errors go away."

How modern DAST cuts down the noise

Fortunately, a new breed of DAST tools reduces the number of false positives. Some of these tools combine DAST with SAST in an approach called interactive application security testing (IAST). Unlike DAST, IAST can peer inside an app while it's running to see which processes might be causing errors. But like SAST, IAST tools must be language-specific.

Another modern DAST approach is to have the tool try to exploit the vulnerabilities it finds to see if they're for real. Sometimes the tools can even provide proof-of-concept exploit code, just as a security researcher would. Invicti calls this "proof-based scanning."

True vulnerabilities may require less work than false positives. Credit: Invicti

Not every flagged vulnerability can be tested by the DAST tool, so developers and app testers will still have to chase some down. But proof-based scanning greatly cuts down the number of false positives, reducing the noise around app testing and letting security staffers focus on the real threats.

Invicti's DAST tool, which performs proof-based scanning, incorporates IAST so that apps can be tested from the "inside out" as they run, giving DevSecOps teams more insight and accuracy. Invicti's tool can also run 24/7 and runtime-test bits of code earlier in the software development life cycle.

"When you have a DAST platform that actually does what it says on the tin and delivers on the promises of speed, accuracy, and integration," said Invicti's Banach, "you can automate the testing process to launch full or partial scans when you want and how you want."