John, I think this has to do with what you want to achieve when you explore

A static analysis tool is a fancy sort of pattern matcher.  If the kinds of
patterns you're interested in aren't that fancy, ("does the program use
function X()?"; "what is the class hierarchy?") then a fancy pattern matcher
is overkill.

If your version of code exploration include things like "is function A()
always called before function B()?" or "is it possible for this data
structure Z to be populated with the result of function X()?"  then you're
in the realm where a static analysis tool might help.

Of course, a static analysis tool allows you to take shortcuts, so you may
learn less about the code than you would if you had to answer these
questions the hard way.


Date: Fri, 03 Feb 2006 13:39:36 -0500
From: "John Steven" <[EMAIL PROTECTED]>
Subject: [SC-L] The role static analysis tools play in uncovering
    elements    of design
To: "Jeff Williams" <[EMAIL PROTECTED]>,    "Secure Coding
    Mailing List" <>
Content-Type: text/plain; charset="iso-8859-1"


An unpopular opinion I¹ve held is that static analysis tools, while very
helpful in finding problems, inhibit a reviewer¹s ability to find collect as
much information about the structure, flow, and idiom of code¹s design as
the reviewer might find if he/she spelunks the code manually.

I find it difficult to use tools other than source code navigators (source
insight) and scripts to facilitate my code understanding (at the

Perhaps you can give some examples of static analysis library/tool use that
overcomes my prejudice<or are you referring to the navigator tools as well?

John Steven        
Principal, Software Security Group
Technical Director, Office of the CTO
703 404 5726 - Direct | 703 727 4034 - Cell
Cigital Inc.          | [EMAIL PROTECTED]

4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908

Secure Coding mailing list (SC-L)
List information, subscriptions, etc -
List charter available at -

Reply via email to