Share with Your Network
It’s no secret that application security professionals face an uphill battle as they attempt to influence development teams to remediate critical application vulnerabilities. But why is it such a seemingly insurmountable challenge? Obviously, the rush to release is a big part of it, since it drives most development teams to commit precious little time to security activities. But there’s another factor that gets largely ignored; it’s the security tools they’re using to find application vulnerabilities. The number of tools, the fact that they often sit in different places in the application development lifecycle, and the resultant silos all present unique and difficult challenges to securing an organization’s applications.
An Abundance of AppSec Tools
For years application security (AppSec) experts have debated which tools are the best at finding application vulnerabilities. In the beginning, DAST (dynamic application security testing) was the de-facto standard for all things AppSec, and it’s still considered by many to yield the best, most trusted results since it mimics actual attackers, and is even used by many attackers themselves.
But the major issue with DAST is that it comes late in the game—almost exclusively relegated to post-production. That’s considered too late for many forward-thinking development teams, especially those employing DevOps and other modern development methodologies, as they attempt to “shift left” to detect issues early in the development cycle. As a result, SAST (static application security testing) was born. While SAST certainly achieves the goal of detecting vulnerabilities much earlier in the development cycle, it’s also plagued by a high percentage of false positives.
Further complicating the challenge is the fact that open source software comprises an increasing percentage of most custom applications—upwards of 80 to 90 percent, according to some studies. As a result, SCA (software composition analysis) is increasingly important to efficiently find known vulnerabilities in open source libraries. But SCA only assesses open source and is only as good as the database it links to.
Of course, most AppSec teams also employ penetration testing to find and remediate their application vulnerabilities before attackers do. While pen testing programs typically yield valuable results, like DAST, it also occurs at the end of the software development lifecycle, so vulnerabilities are discovered too late to enable the team to be truly proactive.
The Challenge of Such an Abundance
As you can see, there are a wide variety of tools used throughout the application development lifecycle. And this is just the start of the list. The problem is, each of them only provides a portion of the context AppSec teams require to understand which vulnerabilities pose the greatest risk, and therefore effectively prioritize which ones should be remediated first. And since each of these tools is typically used by a different team, the results discovered by each are isolated from one another. As a consequence, nobody ever gets the full picture. This makes it nearly impossible to gather the context required to influence development teams to remediate the enterprise’s most critical application vulnerabilities.
But arguably a much larger problem is that these tools can conceivably find many of the same vulnerabilities, but each discovers different aspects of the vulnerability and reports them in different formats. So, while each tool may well find the exact same vulnerability, that fact is typically difficult to decipher, since each employs and displays results in a completely different format. This can result in significant duplication of duties, as multiple teams seek to remediate the same vulnerability. Scoring can also be different for each of these tools, creating confusion regarding the level of priority for each remediation.
The Solution: Multiple Tools and a Platform With a Consolidated View
Since each tool only provides a small portion of the context needed to make appropriate decisions, AppSec teams really need to use all of these tools to gain the degree of visibility required to confidently advise development and DevOps teams regarding remediation decisions and make the best use of these limited resources. Otherwise, they don’t truly have enough visibility into their application vulnerabilities to ensure that they’re not needlessly pulling development teams off of their core responsibility for getting features out the door.
But with so many disparate tools, the problems associated with duplication are every bit as serious as the vulnerabilities, themselves, since they can impede development efforts, thereby grinding the business to a halt. That’s why it’s essential to use a risk-based vulnerability management platform that can integrate with the application security data from all connected application information sources, and then normalize, de-duplicate, and correlate those findings to calculate the risk of application vulnerabilities and display it as a simple risk score.
By using a platform that’s capable of doing all of this, you get the best of both worlds—you benefit from the full context that can only come from using the entire complement of application security tools, while the ability to normalize and de-duplicate the data from these various sources avoids the confusion that can lead to duplication of duties amongst multiple teams. This results in data that you can truly stand by to effectively influence engineering prioritization—enabling you to focus your limited development and DevOps resources on reducing the most application risk.
For more information on the comparison between SAST and DAST, listen to our webinar,“Why All These Vulnerabilities Rarely Matter.” Or learn about “Successful Application Security Strategies,” with a particular emphasis on SCA.
