We should all know by now that the earlier you find and fix flaws in software, the less it costs. An IBM benchmark study revealed that it costs a whopping 100 times more to find and fix flaws after the software has been released compared to finding them early in the Software Development Life Cycle (SDLC). What you may not realize is that best practices in Application Security Testing (AST) are recommending that you use several different static source code analysis tools, along with dynamic penetration testing, checking the vulnerability status of third-party libraries incorporated into the code base, and manual code reviews. By using hybrid analysis techniques you get the best vulnerability coverage and get to see the attack surface of the software application before the attackers do.
But how do you manage all the results from these hybrid analysis techniques? Surely they will find some of the same vulnerabilities and you don’t want to chase down the same problems more than once. And how do you prioritize the thousands of vulnerabilities that will be found with multiple tools and techniques?
Our newest version of Code Dx, officially released this week, addresses these issues. Code Dx Enterprise now incorporates the results of up to eight different Dynamic Application Security Testing (DAST) tools and consolidates the DAST results with the results from up to fifteen different Static Application Security Testing (SAST) tools, two third-party vulnerability checkers, and your manual code reviews in a centralized vulnerability management console. But it doesn’t just leave you with a heap of vulnerabilities. In our newest version we map those vulnerabilities to eight industry standards, so you can see which vulnerabilities the industry experts think are most important. And, of course, we give you all those vulnerability management services that current Code Dx users already love: an easy to use interface for triaging, prioritizing and filtering vulnerabilities; assigning vulnerabilities to developers along with the specific line(s) of problematic code and remediation guidance; and tracking of the remediation process.
But let’s get back to running and combining both SAST and DAST tools against the same code base. Why would you want to do that? Because they each do something different and important.
Static Application Security Testing (SAST) tools are used early in the SDLC to test the application from the inside out which is typically called white box testing. SAST tools do not require a running system to perform an evaluation because they test the source code, the byte code or the binaries line by line and identify exactly where the weakness is in the code itself.
Because each SAST tool tends to only focus on a specialized subset of potential weaknesses, you need to run several of them to find the majority of vulnerabilities in your source code. Yep, you have to run at least three SAST tools on your source code. Why? A benchmarking study by the National Security Agency (NSA) Center for Assured Software found that the average SAST tool covers only 8 of 13 weakness classes and finds only 22% of the flaws in each weakness class. And typically each tool tends to find different classes of weaknesses, resulting in little overlap between the results of different SAST tools. So, you have to run a bunch of different ones to get really good vulnerability coverage.
But while SAST tools are needed, they are not enough because they don’t identify the vulnerabilities in third-party components, nor do they tell you which vulnerabilities are apparent when the application is running, i.e. “dynamic.”
That’s why you also need to run DAST tools, which is done from the outside looking in. It is typically called black box testing or application penetration testing because it tests the application while it is running and it tries to penetrate the application in a variety of ways just like an attacker would. Also, source code, byte code and binaries are not required with DAST tools which tend to be easier and less expensive than SAST tools. DAST tools also look at all of the pieces in Code Dx Enterprise and make sure that all of these interactions taking place among the different components of your application are secure as well. The newest version of Code Dx Enterprise can incorporate the results of eight different DAST tools: Acunetix, Arachni, Burp Suite, HP Webinspect, IBM AppScan, Netsparker, OWASP ZAP, and Veracode.
So…let’s say you can now have SAST, DAST, third-party library analysis and manual results. What do you do with the results? You need to consolidate and de-duplicate the results, conduct a hybrid analysis, prioritize the vulnerabilities, assign them for remediation and track the remediation. That’s what Code Dx does.
The newest version, released December 9, provides a boatload of other new capabilities as well. We’ve answered the request of many of our users by offering integration with the JIRA issue tracker, allowing users to associate Code Dx findings with JIRA issues and assign them to the development team for remediation. We’ve added the ability to incorporate results of Android Lint so you can see and manage vulnerabilities in mobile code. And we now map vulnerability results to the Common Weakness Enumeration (CWE) and industry standards (OWASP Top 10; CWE/SANS Top 25; CERT Java and C/++ coding standards; Seven Pernicious Kingdoms (7PK); Web Application Security Consortium (WASC); Comprehensive, Lightweight Application Security Process (CLASP); and Software Fault Patterns (SFP)).
This is a major release, with significant new functionality already available to our current subscribers. If you haven’t tried Code Dx before, or were waiting for some of these hot new features to hit, now’s the time to download a trial version of Stat! or call us for an evaluation version of Code Dx Enterprise. And then send us comments and let us know what you like and what you’d like to see in the next version. We read all your comments and give them serious consideration as we chart our product roadmap.