There are a variety of tools available to locate security bugs in code. They range from simple ‘glorified greps’ that look at the text of the code for bug patterns, to tools that shadow the build process, build their own representation of the code like a compiler does and analyze the program looking for problems at a deeper level. These tools range from free to very expensive. They don’t get tired. They don’t lose focus. They don’t want to go home at the end of the day. They can continue working night and day without any break.
The simpler tools look for patterns in the code and do not require that the code be complete enough to compile. These ’glorified greps’ are quick and easy to use. They simply look at the text of the code for problem patterns. These patterns can be as simple as looking for dangerous and deprecated functions that should no longer be used, to more complex patterns like the creation of database queries through string concatenation. Since they don’t require the code to compile, they can be used as soon as the code writing process begins.
Some of these tools that examine the text of the code can run automatically. Code Sight checks code for issues anytime a file is opened or saved. Klocwork provides on-the-fly checking and will find bugs as the developer types. When tools automatically check a developer’s code, they provide a secondary benefit of actually teaching the developer to avoid making these common mistakes. Most other tools require the developer to explicitly launch the scan but they still provide tremendous value by finding common bugs.
The better versions of these simpler tools will provide remediation advice for fixing the bugs. These tools have their downsides; for example, a higher false positive rate (findings that are not really security bugs) which can waste a developer’s time. But, the automated tools are a valuable piece of the puzzle to help keep some of the common security bugs from ever being checked in, let alone make it into production.
Advanced static analysis tools move beyond simple pattern checking and take into account the data and control flows of code. They usually require the code to be more mature. Advanced static analysis tools can track data throughout the call stack and recognize issues like where external input is improperly used to create a database query after several function calls, or where a buffer overflow originates seven or eight layers deep in a call stack. Errors like this are difficult, tedious and time consuming for a person to find, but they are easy for the computer. This is not quick for a computer to do. But, computers do excel at tedious and detailed work like this and don’t get tired in the process. These tools can take anywhere from several minutes to several days to run, depending on the amount of code being scanned; but the level and complexity of the type bugs they can find are worth the wait.
Both types of tools, the ones that simply look at the text of the code and the ones that look deeper, can be run at a variety of times throughout a project’s life cycle. They can be run on demand at a developer’s work station or by a security-focused code reviewer. They can be run right away or be injected into the routine build process to produce results which can be evaluated after the build. They can be run often or at set points along the project’s life cycle. No matter when they are run, they will help you avoid introducing certain classes of security bugs before your code ever reaches testing or production.
Over time, the trends in the tool’s results become very useful information for program managers. If a certain type of bug keeps appearing more often than others, it becomes an obvious candidate for developer training. If the number of bugs do not go down over time, it may mean that the security bugs are not being fixed. (Although that can also just mean there is a lot more code or that the scanning rules have changed from one run to another.) Areas within code with the greatest number of bugs, or the highest severity bugs, are areas to concentrate on both in fixing the code and in testing it.