Secure programming is NOT just good programming

[leichter_jerrold at emc.com (Leichter, Jerry)]

| > The only way forward is by having the *computer* do this kind of
| > thing for us.  The requirements of the task are very much like those
| > of low-level code optimization:  We leave that to the compilers today,
| > because hardly anyone can do it well at all, much less competitively
| > with decent code generators, except in very special circumstances.
| > Code inspection tools are a necessary transitional step - just as
| > Purify-like tools are an essential transitional step to find memory
| > leaks in code that does manual storage management.  But until we can
| > figure out how to create safer *languages* - doing for security what
| > garbage collection does for memory management - we'll always be
| > several steps behind.
| 
| It is not adequate to *create* safer languages - it is necessary to
| have developers *use* those languages.  Given the emphasis on C and
| C++ within posts on this list, that seems a long way off.
Fifteen years ago, the idea that a huge portion of new software would be
developed in garbage-collected languages with safe memory semantics
would have seemed a far-off dream.  But in fact we are there today,
with Java and C#, not to mention even higher-level from Python to Ruby.
(Of course, then you can go to PHP.  We know how secure that's turned
out to be... though that's not really a fair attack:  The attacks against
PHP are "new style" - directory traversals, XSS - and nothing out there
provides any inherent protection against them either.)

Yes, there is still *tons* of C and C++ code out there, and more is still
being developed.  But there are many places where you have to justify
using C++ rather than Java.  (There are good reasons, because neither
Java no C# are really quite there yet for many applications.)  

In any case, language is to a degree a misdirection on my part.  What
matters is not just the language, but the libraries and development
methodologies and the entire development environment.  Just as security
properties are *system* properties of the full system, "good for
development of secure systems" is a system property of the entire
development methodology/mechanism/environment.  C/C++ plus static
analysis plus Purify over test runs with good code coverage plus
automated "fuzz" generation/testing would probably be close to as good
as you can get today - not that any such integrated system exists
anywhere I know of.  Replacing some of the C/C++ libraries with
inherently safer versions could only help.

It's not that training in secure coding practices isn't important.
We're starting from such a low level today that this kind of low-lying
fruit must be picked.  I'm looking out beyond that.  I think security
awareness, on its own, will only get us so far - and it's not nearly
far enough.
                                                        -- Jerry