| > 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
_______________________________________________
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
