Interesting tidbit in iDefense Security Advisory

[Jason.Bennett at thales-esecurity.com (Bennett, Jason)]

------------------------------

Message: 3
Date: Thu, 28 Jun 2007 14:47:30 -0400
From: "David A. Wheeler" <dwheeler at ida.org>
Subject: Re: [SC-L] Interesting tidbit in iDefense Security Advisory
        06.26.07
To: sc-l at securecoding.org
Message-ID: <46840242.7090808 at ida.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On the comment:
> | I am not disagreeing with the fact the static source analysis is a
> | good thing, I am just saying that this is a case where it failed (or
> | maybe the user/developer of it failed or misunderstood it's use). Fair
> | enough that on this particular list you are going to defend source
> | analysis over any other method, it is about secure coding after all,
> | but I definitely still strongly disagree that other methods wouldn't
> | have found this bug.

Actually, I am _not_ of the opinion that analysis tools are always 
"better" than any other method.  I don't really believe in a silver 
bullet, but if I had to pick one, "developer education" would be my 
silver bullet, not analysis tools.  (Basically, a "fool with a tool is 
still a fool".)  I believe that for secure software you need a SET of 
methods, and tool use is just a part of it.

That said, I think tools that search for vulnerabilities usually need to 
be PART of the answer for secure software in today's world.  Customers 
are generally _unwilling_ to reduce the amount of functionality they 
want to something we can easily prove correct, and formally proving 
programs correct has not scaled well yet (though I commend the work to 
overcome this).   No language can prevent all vulnerabilities from being 
written in the first place.  Human review is _great_, but it's costly in 
many circumstances and it often misses things that tools _can_ pick up. 
So we end up needing analysis tools as part of the process, even though 
current tools have a HUGE list of problems.... because NOT using them is 
often worse. Other methods may have found the bug, but other methods 
typically don't scale well.

Totally agree with the analysis tools not being a 'silver bullet' and being
just another part of the toolkit for producing secure (what ever this
means!) software. I think a mistake that companies make is assuming that
analysis tools are a substitute for security training. To my mind the tools
are really for auditing and enforcement purposes as to the effectiveness of
the security training but are limited if just used on their own. The tools
are great at taking the mundane work out of code reviews and also take into
account that humans are fallible and just because they did something correct
once doesn't mean they'll do it correct the next time but security training
is essential.

... a "fool with a tool is still a fool" - this has been true for so long be
is still amazes me how often this is discarded. It seems that the first
answer to any software engineering problems is to throw more expensive tools
at it instead of remembering it's good engineers that solve problems not
good tools.


Consider the environment before printing this mail.
"Thales e-Security Limited is incorporated in England and Wales with company
registration number 2518805. Its registered office is located at 2 Dashwood
Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15
2NX.
The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access to it
by any other person is unauthorised. If you are not an addressee or the
intended addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful. If you have received this e-mail in error
please delete it (and all copies) from your system, please also inform us
immediately on +44 (0)1844 201800 or email postmaster at thales-esecurity.com.
Commercial matters detailed or referred to in this e-mail are subject to a
written contract signed for and on behalf of Thales e-Security Limited".