Excerpt from my latest blog post at Cigital…
More and more organizations are using static analysis tools to find security bugs and other quality issues in software long before the code is tested and released. This is a good thing, and despite their well-known frustrations like high false positive rates and relatively slow speeds, these tools are helping improve the overall security of software. Unfortunately, these known frustrations may also introduce a dangerous blind spot in these tools which do not know modern frameworks as well as they know the base languages.
The blind spot
Frameworks are doing more and more of the basic work—providing common functionality of an application. This is a fantastic leap forward in terms of productivity and the ability to release software faster and faster. This frees up more time to focus on the core business functionality of applications.
Sometimes these frameworks are clearly separate things (like Spring, for example) and sometimes they are a mix of basic functionality and advanced features (like the .Net Framework where the tools understand some features but not others). These frameworks are virtually exploding around us, offering many options to take care of the basic drudge work of application writing.
This explosion is happening fast and it seems to be accelerating. New versions and even new frameworks are appearing faster than most can keep up with. Static analysis tools are doing a decent job keeping up with basic languages. However, there is almost no way they can keep up with all these frameworks and handle even a few of them well, let alone all of them. As these frameworks take care of more and more of the plumbing within applications, this inability to understand what they are doing creates a blind spot in which code gets scanned and nothing gets reported.
Frameworks create data flows that the static analysis tools may be blind to. They introduce sources of tainted data that the static analysis tools know nothing about. Therefore, there is nothing to trace to the sinks created in code where problems could occur. These frameworks may introduce new sinks, but since the tools do not know of them, the sources in code cannot be traced to them. They also provide functionality behind the scenes that the static analysis tools do not see at all.
If the static analysis tools cannot see it, they cannot report it. If they do not report it, organizations are left feeling secure when they are not.
False positives are annoying. False negatives are dangerous.