Year Of Security for Java – Week 24 – Use Static Analysis

No Gravatar

What is it and why should I care?
Static analysis is the analysis of software that is performed without actually executing programs built from that software. Essentially, it’s automated inspection of source code. There are varying levels of complexity achieved by the different static analysis tools available. I will roughly group them into a couple of buckets: grep+ and data/control flow analysis.

Grep+
Grep is a great tool and you can do a lot with it, but it’s not really meant for serious static analysis. The earliest tools started here, but found out it wasn’t the best idea. You can certainly do simple things like “calls to this function (strcpy) are bad”. You can add in regular expressions and get a little better, but it usually gets unwieldy pretty quickly. There is some marginal value to be found here, but not a lot. While there are still some tools available today that work this way, most of the useful ones have moved beyond these techniques.

Data/Control Flow Analysis
Data Flow Analysis and Control Flow Analysis are (generally) the current standard techniques for the more advanced static analysis tools. These concepts are not new, but rather originated in compiler theory, specifically related to optimization techniques (Dragon book, anyone?). While the concept is not new, it took quite a while for it to be used heavily outside of compilers.

In general, these tools build up a data structure model (referred to as the AST – Abstract Syntax Tree) of an application, and then traverse the AST in various ways using different types of analysis to look for issues. There are lots of different types of analysis that can occur at this stage, but these tools generally use this as the model on which to base their analysis.

We as developers actually use these concepts constantly in the form of our IDE’s. These tools load up an AST and constantly do checks and will give you warnings and errors that are based on static analysis. Some IDE’s even include AST-driven security-related checks out of the box.

Note: While static analysis has no actual ties to security per-se, I’ll be referencing it’s use with respect to security since that’s the topic here. However, just note that these techniques are useful to solve general analysis problems, not only security. Also note static analysis specifically used for security is often referred to as Static Application Security Testing (or SAST) in the industry.

What should I do about it?

Beyond what you get in your IDE, you should use security focused static analysis as and embed it as part of your development process. I usually see tools deployed either in a single execution mode (collect your code and push “run scan now”) or in a continuous integration mode (scan automatically kicks off every time code is committed). Your environment may dictate that to an extent, but if your tool is good (and/or you’ve tuned it properly), then using it in continuous integration mode is a big win since you’ll find the issues earlier in the cycle and can often address them much easier.

I won’t venture into the debate about which product is better than another (especially given I currently work for a vendor), but I will say that all of them have trade-offs (like any tool), and that you should consider the tools carefully before including them in your environment. If you’re a Java shop, and want to get started (for free !!!), then I’d suggest taking a look at the excellent FindBugs from the folks at UMD. It’s a great tool to use and to learn how static analysis works if you’re interested.

A couple of caveats related to static analysis, specifically those tools that use it for security:

1. Static analysis tools do get the (sometimes well-deserved) bad rap that they produce too many false-positives. My experience with these tools is that you usually need to tune them (either yourself, or pay for some help) to get good results for your environment. This is an additional investment to consider, but can drastically improve your experience with the product. I mention it because I think it’s helpful to know going into the process.

2. While SAST tools are good at finding issues, they don’t find them all, and they’re not a replacement for testing your code.

Finally While static analysis doesn’t solve the security problem, I hope I’ve shown it is a good tool to have in your tool-belt when it comes to securing your applications.

[Full Disclosure] I currently am employed by a company that just released a static analysis product, which I work on. However, I can certainly say I recommended the use of static analysis tools before joining and will continue to suggest their use in the future irrespective of my employer.

References
———–
http://en.wikipedia.org/wiki/Static_program_analysis
http://en.wikipedia.org/wiki/Data_flow_analysis
http://en.wikipedia.org/wiki/Control_flow_analysis
https://blog.whitehatsec.com/mythbusting-static-analysis-software-testing-100-code-coverage/
http://swreflections.blogspot.com/2012/01/static-analysis-isnt-development.html

Be Sociable, Share!

Technorati Tags: , , ,

2 thoughts on “Year Of Security for Java – Week 24 – Use Static Analysis

Leave a Reply

Your email address will not be published. Required fields are marked *