Secure Coding mailing list archives

Root Canal Treatment vs Source Code Review


From: Everhart at gce.com (Mary and Glenn Everhart)
Date: Mon, 30 Jun 2008 22:43:37 -0400

Jonathan Leffler wrote:
Under the subject "InternetNews Realtime IT News - Merchants Cope With PCI 
Compliance", Kenneth Van Wyk <ken at krvw.com> wrote:
[...] In talking with my customers over the past several months, I always 
find it interesting that the vast majority would sooner have root canal 
than submit their source code to anyone for external review. [...]

There's a simple reason for that reluctance - most people are painfully 
aware that their software won't stand the scrutiny that an external review 
would entail.

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

_______________________________________________
Secure Coding mailing list (SC-L) SC-L at securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
_______________________________________________
  
There is another reason I have seen quite often: you can't readily ask 
the designer of
the code what it does when he is dead, or when he has left the company 
(esp. if he works for a competitor). In many such situations I see code 
that gets touched at all with
great fear and trembling, because people are not certain they can build 
it all from
sources.  Eventually that gets replaced, but in some cases that may be 
long delayed.

I've used a few tools to analyze code, and noticed that mostly they 
don't really know
how trustworthy external information is (or even, for sure, what is 
external). Result is
much hand winnowing needed. Still they seem to take less looking than 
learning
an entire code base.

I still favor trying to characterize what functions are supposed to be 
invoked by
calls to routines and trying to characterize this for each 
call....giving rise to
a hopefully small number of permitted patterns for any call location. 
Obviously
this is much easier to do for interpreters like SQL than HTML, but the 
approach
may do better against future attacks than other approaches.

Glenn Everhart


Current thread: