Using static source code analysis as a security tool and an information risk management tactic is nothing new....
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
The tools are mature and the benefits of integrating source code analysis into the SDLC have been pushed on us for years. Even with all this knowledge it occurs to me that many people – developers, QA testers, network managers, and security executives alike – still don't quite understand what's involved with source code analysis. When talking with existing and prospective clients, many people don't initially see the value in source code analysis and are, therefore, reluctant to invest any money in it. It's as if they have certain pre-conceived notions that were perhaps brought on by the security marketing beast. Usually once they get past the vendor fluff and hear the good, bad, and ugly about source code analysis, they're able to make informed decision as to whether or not it's a good fit for their business. Here's my take on it.
What is static source code analysis?
It's the process of running a scanning tool against your source code (C#, Java, VB.NET, etc.) to uncover security and other quality issues. The word "static" is used because the process looks at the source code from a static perspective. Certain source code analysis tools can also perform dynamic analysis (sometimes dubbed hybrid analysis) that looks at generated code and other behaviors during application run time.
What's in it for you?
First, off it's very easy to do. It also automates the manual analysis process – something that's often an exercise in futility especially with today's complex applications. It can find defects that the human eye, and oftentimes penetration testing tools, would never find. Obviously there's a compliance payoff – the thing that management typically understands and likes to see in this context. More secure applications equals less worry over security breaches and compliance violations and audit failures. Finally, it's not just for Web applications. You can test any source code regardless of how it's used: client/server, browser helper objects, standalone applications, you name it – there's a tool out there for you.
What tools can be used?
Options include commercial products like Checkmarx and Klocwork Solo as well as freeware/open source tools such as Microsoft's FxCop and FindBugs. Some static analysis tools plug into your IDE while others are standalone products. Being a security consultant I prefer the latter so I don't have to worry about keeping a copy of Visual Studio or other IDE on my test system. However, developers and testers may prefer it that way. Do yourself a favor and get a trial version of any products you're considering before making the leap.
How long does it take?
Some static analysis scans I've done have taken only a few minutes, others have taken upwards of an hour, while others didn't finish at all due to incompatibilities between the source code and the tool I was using. So, it depends. Determining factors include the amount of code you're testing, the processing power of your test system, and the tool you're using. By large it's a simple and quick process.
What are some common security vulnerabilities found during the process?
Depending on the type of code you're testing and the tool you use, you may find issues similar to what you uncover during penetration testing such as cross-site scripting and SQL injection. Hopefully you'll find others that are not so obvious. Vulnerabilities I've come across that were unique to static analysis include improper resource shutdown situations in C# that could lead to denial of service conditions, unused methods in Java that can create backdoor access, weak implementations of encryption and data storage, general error handling and recovery, and, of course, buffer overflows. The possibilities are endless. All in all many of these issues could take an eternity to uncover doing a manual code reviews but are still exploitable application vulnerabilities nonetheless. This is why you need to consider static source code analysis in addition to penetration testing. It's the only way to find everything that counts.
What are the drawbacks?
Source code analysis is in no way a replacement for blackbox security assessments/penetration tests that involve automated scans and manual analysis from a hacker's eye view. I can say that in the security assessments where I've done both penetration testing and source code analysis, the penetration testing by far revealed the majority of the application weaknesses. But it was the handful of nuggets that the source code analysis revealed that helped make a big difference. Furthermore, if you're looking for an independent view of your source code rather than performing this exercise in house, the expertise is kind of sparse. There's also the issue of price with the commercial static analysis tools. If you've looked into this much I'm sure you've noticed that some vendors are very proud of their products and want to charge you accordingly while others are priced very reasonably considering the return you're going to get. Capitalism and competition at their finest! It's your choice – just do your homework first and make sure you find the best fit.
With the presence of Web applications across virtually every facet of the business, it's important that you do what you can to minimize your security risks. This is where testing your actual source code comes into play. While static source code analysis is not everything it'll certainly help you assess your entire attack surface and it's a worthy component of an overall information security strategy you, and especially the powers that be, need to be thinking about.
.About the author: Kevin Beaver is an independent information security consultant, speaker and expert witness with Atlanta-based Principle Logic, LLC. He has over 20 years experience in the industry and specializes in performing independent information security assessments revolving around compliance and information risk management. Kevin has authored/co-authored seven books on information security including the ethical hacking books, Hacking for Dummies and Hacking Wireless Networks for Dummies (Wiley). He's also the creator of the Security On Wheels IT security audio books.