Building security into software applications from the initial phases of the development process is critical. Static source code analysis techniques give application developers the ability to review their code without actually executing it to uncover the potential security vulnerabilities and address them earlier in the process. InfoQ spoke with Brian Chess (from Fortify, an HP company and a co-author of the book Secure Programming with Static Analysis) about security code analysis and how it compares with other security risk assessment techniques like application penetration testing.

InfoQ: Can you tell our readers your current role and what projects you are currently working on?

Brian Chess: At Fortify my title was "Founder / Chief Scientist". At HP I'm now a "Distinguished Technologist". All the fancy words boil down to the same thing: I get to spend my time thinking and talking about the future of software security. When I'm out and about, that mostly means talking to people about the realities of the problems they're having right now. When I'm in the office, that means talking to engineers about how we can solve those problems. These days I'm most excited about the work we're doing in software testing. Testing is a strong point for HP Software, and there's much to be done to marry software testing with security.

Related Sponsored Content The DevOps Engineer's Guide to Kubernetes Configurations Best Practices

InfoQ: What is Static Analysis and how does it help in secure programming?

Brian: Static analysis is about finding problems in code without executing it. You know all of the warnings and errors a compiler can throw back at you? That's static analysis. Static analysis for security is just analyzing the code to find the kinds of problems that lead to vulnerabilities. Static analysis is good at turning up all sorts of odd corner cases that people often miss and that don't get executed during normal testing. Hackers are good at doing the same kind of thing, which is why static analysis is particularly good for security.

InfoQ: What are the different security analysis techniques available to developers?

Brian: Think of any technique developers use to make sure they're producing good software, and there's a security analog. Design review/threat modeling, compile-time checking/static analysis, regression testing/security testing, system testing/penetration testing. Making secure software is part of making good software.

InfoQ: How do static analysis techniques compare with other security assessment approaches like application penetration testing? What's the best way to get "best of both worlds" from static analysis and penetration testing efforts?

Brian: Static analysis is great for catching common errors early. You don't need to understand all of the vulnerabilities in order to find them—the automation takes care of it. By way of contrast, penetration testing is usually carried out late in the game, and it involves having a skilled human try every way they can think of to break in. Penetration testing is important because it's the final check, but you can't penetration test your way to good security just like you can't test your way to high quality.

InfoQ: What metrics should the application architects and developers focus on, to get the best of static analysis efforts?

Brian: As part of the BSIMM study I've talked to a lot of companies about the metrics they use for tracking software security. It turns out to be highly specific to the organization. There aren't any metrics I can point to that are used across a wide swath of leading companies. Of course when we're selling static analysis, we love it when people have been keeping track of the vulnerabilities they find during penetration testing. It's not uncommon for a full rollout of static analysis to decrease penetration testing findings by 10x. That's satisfying!

InfoQ: What are the best practices and "gotchas" in integrating static and dynamic analysis techniques into software architecture, design and development processes, especially in those organizations using agile approaches?

Brian: Some gotchas:

If you buy it they will come. Just because the security team buys some software doesn't mean the developers will start caring about security. Until the programmers believe security is part of the job, they won't spend time on it. Let it rip. Chances are a well equipped security team can find vulnerabilities a lot faster than development teams can fix them. Until there's a well-understood cycle in place for handling security as part of software development, the security team can cause a lot of chaos by trying to analyze every piece of code on day #1. Get started with a pilot project.

Agile puts a lot of emphasis on automation. If you have good automation, life is sweet. If you have bad automation, you find out fast. When it comes to security, if you were somehow getting by with penetration testing before, agile is the end of it. In that sense, static analysis is a nice way to get security feedback in a highly automated way and without having to schedule an appointment with the security team 2 months in advance.

InfoQ: A recent trend in software security analysis is static analysis service in the Cloud (Software Security Analysis as a Service). Can you discuss more about this trend and advantages and limitations of this approach compared to the on-premise security analysis?

Brian: We've been selling a cloud-based analysis service for about two years now, and we see two predominant use cases:

Organizations that want a fast and easy way to get started. Organizations that want to get some insight into the security of the code their vendors are providing.

We allow people to move between an on-demand model and an on-premise model. That means that if a company starts with on-demand but wants to transition to managing the process themselves, it's easy to do. For companies that are using on-demand to manage their vendors, they can have the vendors undergo the same kind of assessment that they're performing themselves in-house. We're proud of this capability because it's unique in the industry today.

InfoQ: How can static and dynamic application security testing aid in the Enterprise Security Intelligence (ESI) efforts?

Brian: From an ESI perspective, all of the assessment techniques are part of managing the software supply chain. In other words, they're about getting some control over and insight into the flow of vulnerabilities going into production. Once you have a stream of vulnerability data, you can put it together with the security event stream, and you've got a pretty tight little ESI package. We're having great fun putting these pieces together with our new friends from HP ArcSight.

InfoQ: What is the future direction and trends in the static analysis space?

Brian: Analysis techniques are coming together. Static analysis is great because it's very thorough, but false positives are a fact of life. Black box testing produces very concrete results, but it's very hard to guarantee good coverage. There's a lot we can do to marry up an "inside" and an "outside" approach, but we have to make sure we end up accentuating the strengths and not magnifying the weaknesses.

InfoQ: Thanks for your time. Do you have any other comments or thoughts on the secure programming topic in general or static or dynamic analysis techniques in particular?

Brian: I started working on finding security vulnerabilities with static analysis in 1995. Back then the most common reaction I got was "you're trying to do what?" People thought that either it wasn't possible or that it wasn't important enough to bother with. In 2011 we see software security issues like Stuxnet making headlines, and all major enterprises moving to address software security. It's been quite a ride!

About the Author



Brian Chess is a founder and Chief Scientist at Fortify Software, an HP Company. Brian holds a Ph.D. in computer engineering from the University of California at Santa Cruz, where he studied the application of static analysis to the problem of finding security-relevant defects in source code. Before settling on security, Brian spent a decade in Silicon Valley working at huge companies and small startups. He has done research on a broad set of topics, ranging from integrated circuit design all the way to delivering software as a service.