source code analysis tools

Scanning source code for security flaws: Three best practices

Here’s some quick advice on scanning source code for security flaws. Maty Siman, CTO of Checkmarx, shares his top three best practices for source code vulnerability inspection.

1. Scan early and scan often. “The beauty of not having a compiler-based approach is that code can be scanned any time, anywhere,” Siman said.
2. Use code analysis as a risk benchmark. Be sure your security-optimized code analysis practices and tools eliminate false positives, allowing auditors and CISOs to get a strong handle of enterprise risk.
3. Use code analysis to introduce a culture of security to development.

Remember, said Siman, “the best defense is a strong offense.”

Checkmarx CTO on new compiler-free vulnerability scanner

Recently, Checkmarx CTO Maty Siman filled me in on the new source code security scanner, Checkmarx Virtual Compiler. Designed to enable compiler-free, real-time source code vulnerability scanning, the tool promises to facilitate testing of code throughout the development process without compiler or operating system compatibility problems.

Virtual Compiler will be used by development teams “test uncompiled and unlinked code, their independent modules or any other application subsets in a desktop deployment that reinforces good security awareness and practices as the code is written,” said Siman.

Auditors and chief information security officers (CISOs) can benefit from being able to test code earlier in the software development lifecycle (SDLC), said Siman. They can also use Virtual Compiler to inspect legacy code.

Using source code analysis tools is a must for building secure software, according to SearchSoftwareQuality.com security expert Kevin Beaver. In his tip, The role of QA pros in software security, he wrote that source code vulnerability checkers “are essential for rooting out software vulnerabilities that would otherwise be next to impossible to find.” He names Checkmarx, QAInspect and Klocwork tools as good options.

Virtual Compiler solves some problems that static code analysis tools haven’t addressed previously, Siman said in our interview. Most major static code analyzers have only scanned post compilation and required buildable code. As a result, static code analysis required a complete, buildable project to run against. So, scans usually have to take place near the end of development, and repairs required going back and fixing code whose problems probably manifested themselves and possibly grew during development.

“Checkmarx Virtual Compiler eliminates the buildable code requirement by removing the dependency on compilation and linking for software testing,” said Siman. “It transforms code, whether freshly written or old legacy applications, into a form that contains structure and application flow properties. Testing is not dependent on having all modules complete, duplicating the development environment or creating a final build-test harness. Instead, scanning can take place early, and often, as the code is developed. Once scanning is complete, all code and flow properties are stored in a data base that can be interrogated for vulnerabilities.”

Checkmarx Virtual Compiler is part of a suite of products that can be purchased for onsite use or as a service. Prices for onsite usage start at $15,000.

Tester’s view: IBM buys source code analysis company

In a press release yesterday, IBM announced it would be acquiring Ounce Labs Inc., whose software helps companies reduce the risks and costs associated with security and compliance concerns. IBM will integrate Ounce Labs products into its Rational software business.

For those who might not be familiar, the current lineup of Ounce products include:

• Ounce Core is their security source code analysis engine, used to assess code, enforce rules and policies, and it houses the Ounce security knowledgebase
• Ounce Security Analyst scans, triages and assigns results, and manages security policies allowing you to take action on priority vulnerabilities.
• Ounce Portfolio Manager delivers at-a-glance metrics and information to manage risk enterprise-wide.
• Ounce Automation Server augments Ounce Core by integrating and automating scanning, publishing, and reporting in build environments.
• Ounce Developer Plug-Ins helps pinpoint vulnerabilities and provides remediation advice for rapid fixes.

For those familiar with the latest offerings of IBM Rational, it comes as no surprise that the Ounce Labs products will be offered as part of the IBM Rational AppScan family of Web application security and compliance testing solutions. The current suite of IBM Rational tools (AppScan and Policy Tester) provide some of the basics around security vulnerability scanning, content scanning and compliance testing, but they aren’t as full featured as their competitors products.

When the current Quality Manager suite of tools from Rational came out a year (or so) ago, I was quite happy to see AppScan integrated more closely with the testing products. And over the last several years, Rational has done a better job of integrating their testing and development platforms — moving the tools to a common platform/IDE, etc. Hopefully the addition of the Ounce products will continue that trend of bringing team members together in a common toolset.

For more information on the acquisition, SearchSecurity.com has the full story.

Using source code analysis tools

I found a great article earlier this week on static analysis tools by Mary Brandel. In the article, “How to choose and use source code analysis tools,” she cites some statistics on the static analysis market, including:

• “The entire software security market was worth about US $300 million in 2007″
• “The tools portion of that market doubled from 2006 to 2007 to about $180 million”
• “About half of that is attributable to static analysis tools, which amounted to about $91.9 million”

In the article, Brandel also offers some evaluation criteria for when you start looking at source code analysis tools. These include language support and integration, assessment accuracy, customization, and knowledge base. She also provides some dos and don’ts for source code analysis. I think the most valuable tidbits from that list include:

• DO consider using more than one tool: The article provides a good story about Lint vs. Coverity, and I’ve found that static analysis tools will find different issues as well. Each vendor will have its own specific focus on vulnerabilities and warnings.
• DO retain the human element: While I’ve yet to work with a team that thinks adding automated tools like this will allow you to remove people, there’s certainly the feeling from the marketing materials that the results are intuitive. That’s typically not the case. You often need to know what you’re looking at or you’ll miss the subtleties in the data. I agree with the “truly an art form” quote. This stuff is hard, and while tools make it easier, it’s still brain-engaged work.
• DO consider reporting flexibility: At some companies this is a big deal. When working with smaller software development organizations, it doesn’t matter what the reports look like. The only people looking at them are the people working in the code. However at a larger company, Fortune 500 for example, information like this normally needs to be summarized and reported up.