By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
You've done your automated scans and manual analysis of your Web sites. Penetration testing is complete. Traditional logic says stop there and wait until next month or quarter for the next round of testing. That's made pretty good sense…until now. If you're like most security professionals, developers and QA analysts, the last thing you want to do is add another task to your already over-filled plate. That is especially true for a task you assume is going to take hours -- if not days -- to complete and, in turn, is going to generate that much more work.
I've always been skeptical about what the marketing machine puts out and thus was one of those reluctant people not really buying into the value of source code analysis. I've been proven wrong. These tools really do work.
Based on my experience, the results that are generated by source code analysis tools are equally valuable for developers and security professionals. Figure 1 shows an OWASP Top Ten report of a source code analysis performed by Compuware's DevPartner's SecurityChecker.
Figure 1: SecurityChecker's OWASP Top Ten analysis report
A big plus with the source code analysis tools that I've used is that they don't generate gobs of useless information that doesn't add much value. Instead, they've found a relatively small number of pinpointed issues with only a few false positives sprinkled in. They not only find what's vulnerable but also provide real-world solutions for fixing the problems. The neat thing is that these tools find security-related flaws that have made both developers and QA testers say things like, "Very interesting; I haven't thought about that."
Performing a source code analysis -- be it static analysis or run-time analysis (some tools do both) -- is actually pretty easy. Once you get your tool setup (which typically integrates into Visual Studio, Eclipse or the like), you simply load up your project files, start the analysis and off it goes. Klockwork's toolbar integration into Microsoft's Visual Studio 2005 is shown in Figure 2.
Figure 2: Klocwork for C/C++ toolbar integrates directly into Visual Studio
This allows the person doing the testing to work with everything -- source code, analysis tool and reporting -- all within one interface. Along the same lines, SPI Dynamics has a tool called DevInspect that developers can use to analyze their source code in Visual Studio as they go along before it actually goes into QA and production. I like how most source code analysis tools are tailored for specific users (i.e. security professionals, developers or QA/testers). This helps facilitate the process at the various testing levels and best suits the people who are performing the analysis.
The time required to run a source code analysis depends on several factors, including the number of lines of code, processor speed and memory available. In my experience, it's has taken 10 to 15 minutes tops. Some naysayers argue that manual analysis of every line of code is required to do it right. More power to them. Most of us have way too many other things to do with our time anyway. I'm convinced that it's neither efficient nor effective for a human being to look at tons of code attempting to find security defects. Given the complexity and size of most modern day applications, automated analysis is the way to go.
The downside to source code analysis is that certain tools I've used can be a beast to set up, especially if you're analyzing managed code such as .NET that requires IIS on the local machine and other dependencies that you may or may not have installed. This isn't a big deal for developers and QA folks, since they typically have all the tools they need on their local machine. However, security professionals often do not have the same software running and ready, which can add some extra time and effort to the process.
One source code analysis experience I had involved about a day getting the software installed and working properly and about 20 minutes of running the actual analysis and creating the report. Luckily, I've had good luck with technical support from the various vendors when issues came up. As always, though, documentation is lacking. Don't let any potential setup problems deter you from taking the plunge into source code analysis. The benefits are far ahead of any inconveniences.
One thing I've found in security over the years is that the often-overused concept of a layered defense really works. Adding ongoing source code analysis to your arsenal can serve as yet another security layer for your applications. It will make a difference. You're going to find vulnerabilities that aren't easily uncovered using penetration testing but can be exploited by a malicious attacker nonetheless.
From security auditors to Web administrators to development managers, the benefits of source code analysis are huge for everyone involved. In the end, your organization and/or your customers will be running software of higher quality and management can be assured that you're taking the next big step forward down the path of reducing business risks.
About the author: Kevin Beaver is an independent information security consultant, speaker, and expert witness with Atlanta-based Principle Logic LLC. Kevin has authored/co-authored six books on information security including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley) as well as The Practical Guide to HIPAA Privacy and Security Compliance (Auerbach). He's also the creator of the Security On Wheels series of audiobooks. Kevin can be reached at firstname.lastname@example.org.