{"id":352,"date":"2011-10-03T15:00:10","date_gmt":"2011-10-03T22:00:10","guid":{"rendered":"http:\/\/codecurmudgeon.com\/wp\/?p=352"},"modified":"2015-08-06T11:06:00","modified_gmt":"2015-08-06T18:06:00","slug":"going-with-the-flow-in-static-analysis","status":"publish","type":"post","link":"https:\/\/codecurmudgeon.com\/wp\/2011\/10\/going-with-the-flow-in-static-analysis\/","title":{"rendered":"Going with the Flow in Static Analysis"},"content":{"rendered":"

\"\"<\/a> As part of my ongoing series about Static Analysis<\/span> issues I want to talk about the relationship between the traditional static method and the newer dynamic or flow analysis<\/span> method. People seem to misunderstand how the techniques relate and what each is good at. In particular, many seem to think that flow analysis<\/span> is a replacement for non-dynamic analysis, which couldn’t be more wrong.<\/p>\n

For the sake of having a simple term to identify both methods, I’ll refer to the older “static” method of static analysis<\/span> and “pattern-based” and the newer flow-based method as “flow-based”. This is somewhat of a misnomer in that both types are really based on patterns, but seems to be a somewhat common way of referring to the two methods. If the terms I use bother you, feel free to do a search-replace function in your head when reading. I’m not too worried at this point about a strict technical explanation of each, but rather to their relationship. The goal is to have a way to differentiate in terms these two particular types of static analysis<\/span>. Of course there are other types of static analysis<\/span> as well, but I’ll leave that for another day.<\/p>\n

Let me begin by saying that there is in fact a very strong relationship between pattern-based and flow-based static analysis<\/span>, at least at an academic level. In almost every situation there are a set of pattern-based rules that would allow you to code in such a way that would prevent the occurrence of the issue being found by the flow-based rule. Given the nature of how flow analysis<\/span> works, it can<\/span> never find all possible paths through an application. This makes it a good idea to start programming in a more pro-active way to prevent the possibility of issues you\u2019re concerned about.<\/p>\n

For example, in security, one of the basic<\/span> problems is using tainted data. Somewhere in the application between getting data from the user and operating on the data, you need to check if the data is safe. Depending on how far apart the operations are, it can<\/span> be extremely difficult if not impossible to check every possible path. Security code scanners that rely on flow-based analysis attempt to find possible paths between user input and uses of the input that allow tainted data to be operated on. They can<\/span> never find every possible path even if you let them run for an incredibly long time.<\/p>\n

Instead, if you restructure your code so that input validation is done at the moment of input, then you don\u2019t have any paths to chase, and you don\u2019t have to worry about tainted data in your application. Flow-based tools won\u2019t find anything anymore, because you won’t have any unprotected paths. This is sometimes a more difficult sell for developers, since it doesn\u2019t provide them with a single broken piece of code that needs to be fixed. Rather it tells them that the way they\u2019re writing code now could be improved \u2013 a bitter pill to swallow.<\/p>\n

However applying this same principle to things like memory corruption, resource consumption, etc. can<\/span> make the program far more robust than chasing possible paths ever could. <\/p>\n

An excellent methodology is to start with flow-based analysis and fix the low-hanging fruit. Once you have compliance with your flow-based rule set, then review what you\u2019re doing with flow and compare it to pattern-based static analysis<\/span>. Determine as best you can<\/span> how to apply static analysis<\/span> and catch all possible potential problems before they happen, and put that into place. This moves you from a reacting to issues in your software to a more preventative stance. <\/p>\n

There are those who say that flow-based analysis is<\/i> preventative, but it’s still symptom driven – namely trying to find the openings and bugs you left in your code. Pattern-based analysis<\/span>, when deployed properly, can<\/span> be used to address the root problems. In our tainted data example, this means changing our coding style so that we don’t have paths where data could be tainted – root problem handled.<\/p>\n

Essentially, flow-based analysis finds real bugs in possible paths. When you get a message from it, you just decide whether you care about that path or not. Static on the other hand tells you about the potential for a bug, not necessarily about the existence of a bug. Again, with our security example, Flow-based says “you used tainted data” where pattern-based says “this data could be tainted before use”. <\/p>\n

When compared, you can<\/span> see that flow-based analysis is a great way to find low-hanging fruit, because it’s looking for bugs instead of you doing it. On the other hand, because it works by guessing (flow fans hate the “guessing” term) at possible paths through your code, it will always be by it’s very nature incomplete.<\/p>\n

Pattern-based analysis<\/span> on the other hand requires restructuring your code and behavior if you want to achieve it’s full value. Some code is not well suited to such change, such as working legacy code. <\/p>\n

Used together you have a very powerful solution that is much more robust than either technique on it’s own.<\/p>\n

[Disclaimer]
\nAs a reminder, I work for Parasoft<\/a>, a company that among other things make static analysis<\/span> tools. This is however my personal blog, and everything said here is my personal opinion and in no way the view or opinion of Parasoft or possibly anyone else at all.
\n[\/Disclaimer]<\/p>\n

Resources<\/i><\/p>\n