On Wed, 6 Jun 2007, Wietse Venema wrote: > more and more people, with less and less experience, will be > "programming" computer systems. > > The challenge is to provide environments that allow less experienced > people to "program" computer systems without introducing gaping > holes or other unexpected behavior.
I completely agree with this. This is a grand challenge for software security, so maybe it's not the NEXT problem. There's a lot of tentative work in this area - safe strings in C, SafeInt, StackGuard/FormatGuard/etc., non-executable data segments, security patterns, and so on. But these are "bolt-on" methods on top of the same old languages or technologies, and some of these require developer awareness. I know there's been some work in "secure languages" but I'm not up-to-date on it. More modern languages advertise security but aren't necessarily catch-alls. I remember one developer telling me how his application used Ruby on Rails, so he was confident he was secure, but it didn't stop his app from having an obvious XSS in core functionality. > An example is the popular PHP language. Writing code is comparatively > easy, but writing secure code is comparatively hard. I'm working on > the second part, but I don't expect miracles. PHP is an excellent example, because it's clearly lowered the bar for programming and has many features that are outright dangerous, where it's understandable how the careless/clueless programmer could have introduced the issue. Web programming in general, come to think of it. - Steve _______________________________________________ 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 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. _______________________________________________