Code catcher in a box
The BugScan appliance could be a developer’s best friend: It catches potential security holes in your application code
On the plus side, BugScan travels through all possible avenues of code execution. Consequently, it achieves 100 percent coverage, something that is extremely difficult and time-consuming to accomplish with run-time tests. Based on these pros and cons, BugScan is best employed as part of an overall testing protocol that involves both static and dynamic (run-time) exercises.
Just the Facts
BugScan's report format has no distracting graphics, fonts, or icons; just a header and a table. The header includes the number each of red, yellow, and green alerts. Red alerts are the most severe potential violations, yellow less so, and green alerts indicate secure, well-written code sequences.
Beneath is a table of four columns: Name, Severity, Risk, and Description. The first column is a brief name for the error found, such as "no stack protection." The Severity column lists a number from 1 to 3, indicating the alert level of the problem. The Risk field categorizes the error by type, such as "overflow."
The most useful column is Description, which contains a rather lengthy explanation of the issue found. In many cases, the field begins with the hyperlinked text "Code Sample"; select that link, and a new window pops up containing an example of code illustrating the problem. The code is reasonably well-commented, so you don't waste your time searching for the source of the error.
The Name cells are also hyperlinked. Click on a name, and the bottom of the window is populated with a list of all the hexadecimal locations in the executable where the problem was noted. Initially, I bristled at this presentation: A hexadecimal offset is not exactly user-friendly. I wished for a link into the source code, but that wasn't possible; BugScan processes only the executable.
Luckily, you can track the problem to its source using a method briefly described in the BugScan documentation. You need the symbol information for the executable, which is stored in the PDB (program database) file, and a free open source program called CrashFinder (available as a download). CrashFinder takes the hexadecimal offset (which you can cut and paste out of BugScan) and -- with the help of the PDB -- returns a source file name and line number information. It's not glamorous, but it works.
BugScan will also generate an XML document of the report, which you can save on your file system or in your favorite XML database. The version I tested simply refused to produce the XML document, but HBGary gave me Internet access to its newer version, 2003A (scheduled for release in mid-March), that happily handed me XML when I asked.
Fast — For a Price
Although its examination is thorough, BugScan's current user experience is a little rough around the edges. For example, once a file is in the analysis queue but before analysis is complete, BugScan is somewhat at a loss as to the file's status. The tool literally tells you that either there's been a problem, or BugScan is still working on the file. The solution? You just have to wait patiently, and if the results don't show up in, say, a half hour or so, then something must really be wrong. I pointed this problem out to the BugScan engineers, and they acknowledged the problem, assuring me that it will be addressed in future versions.