An article by Ken Prole, CTO of Code Dx, was published in the Security Today magazine’s April 2019 edition.
After a series of high-profile cyberattacks, most organizations have adopted application security practices when they develop software. They have taken crucial first steps to prevent the kind of attack that devastated, for example, Sony’s PlayStation Network in 2011, an external attack that compromised the personal data of 77 million users, costing Sony a whopping $171 million, and may have been the result of a SQL injection.
While there are a lot of excellent automated tools that can test your applications for known vulnerabilities, industry best practices demand that organizations use multiple tools to ensure maximum coverage. No single tool will cover all the programming languages you need, nor will any provide enough coverage to find the most critical issues.
It sounds easy to use a group of tools together, but that is only because we have come to equate “automated” with “simple.” Though these tools do take much of the weight off the shoulders of your security or development teams, using them creates some big problems. Mainly, instead of one set of results, you have to handle three, or five or ten.
When you use one tool, the application security testing process is simple enough, though it isn’t exactly easy or fast (and, more importantly, it isn’t nearly complete enough). Your designated security team runs the tool to test the application, sifts through the results, prioritizes the vulnerabilities they’ve found, then sends the list to the development team for remediation.
Using more than one means you need to do this for each tool, separately—and then you need to add another step, during which your security team painstakingly removes duplicate results and combines the different lists into a single set.
This creates a serious bottleneck in the development cycle, especially for those who have adopted continuous integration approaches—imagine doing this on a weekly (or even daily) basis. It has a measurable, significant impact on companies’ bottom lines, affecting things that really matter in the software development world, like time to market—not to mention how expensive it is.
Further, all of these results need to be verified and confirmed to be true vulnerabilities. Automated testing tools, notably SAST tools in particular, tend to produce a significant number of false positives. These are vulnerabilities that are only technically vulnerabilities, without necessarily being threatening. A big chunk of these false positives are simply not accessible by end users without administrator privileges, for example. A crucial step in the application security process is to determine which vulnerabilities are exploitable, and triage the results your tools provide based on severity and exploitability.
Aside from the technical side of things, strong communication is critical to successfully manage this type of operation. Your security and development teams need to work extremely well together, with agreed-upon inter-departmental formatting and shared priorities. Without solid communication, the whole process will fall apart.
That’s why many industry leaders have started to use application vulnerability correlation and management tools to reduce or eliminate the problems that using several AppSec tools creates.
These tools automate the tedious, expensive, time-consuming processes that are most responsible for the application security bottleneck. Instead of manually correlating the results from one tool with the next, these tools do that for you. All of the results many of which use different nomenclature—are processed into a single list, with no duplicate entries, and are prioritized against a common scale.
Many of them provide functions to triage the results easily, with threat levels plainly shown. Some integrate communication tools, so your development and security teams can work together from one place, and track the progress on vulnerability remediation. Some even provide unique benefits not found in most individual application security testing tools, like checking your code against regulatory compliance standards.
The difference between using one of these tools and not using one of these tools is dramatic; weeks, even months of development time can be saved, during which an organization can either add more features or compatibility to the application, or simply beat a competitor to market.
When given the choice to use an application vulnerability correlation and management tool, the question really becomes: Why wouldn’t you?