Stephan Neuhaus wrote: > > and deploy software. I see no reason why teaching to think about > assumptions should be deferred. You teach math students how to do proofs > right from the beginning for essentially the same reasons :-) > You don't teach proofs - not really. The elementary and junior high curriculum generally does not contain anything about proofs (if it does, then that program is rare - especially in the NCLB era - unless you're considering use of manipulatives to be a "proof" with which I would disagree as it's merely empirical). You have to teach the basic constructs. You have to ingrain the fundamentals. The same is true for coding.
The good news, perhaps, is that you're not generally teaching 1st graders how to write code. So you can go into more advanced topics with high school or college students. Nonetheless, these programs rarely resemble anything in real life. You talk about assumptions - this is one of the biggest - that CompSci curricula actually teaches much of anything relevant to enterprise life. Anyway. I again come back to James McGovern's suggestion, which is treating coding as an art rather than a science. It increasingly makes sense given the failures up to this point. Though, at the same time, I stick with my original 2nd point, which is that as soon as coders can take short-cuts, they will, because deadlines rule the day. > Unfortunately, security assumptions are rarely written down so I don't > see how they can be enforced at the language or compiler level. > Here you make a patently bad assumption yourself. It should be possible for the compiler to automatically protect against overflows, as an example. Safe input validation and output encoding could also be forced at a given level. Compiler/interpreter - it doesn't matter, as long as you're not expecting a human coder to do extra work under deadlines and duress to "do things right" (especially when it conflicts with "doing the right thing" which is getting the job done and keeping one's boss happy). We should be seeking to innovate outside the box - change the rules of the game dramatically - rather than trying to work within the arbitrary constructs we've placed around ourselves. -ben -- Benjamin Tomhave, MS, CISSP fal...@secureconsulting.net Blog: http://www.secureconsulting.net/ Twitter: http://twitter.com/falconsview Photos: http://photos.secureconsulting.net/ Web: http://falcon.secureconsulting.net/ LI: http://www.linkedin.com/in/btomhave [ Random Quote: ] Sturgeon's Revelation: "Ninety percent of everything is crud." http://globalnerdy.com/2007/07/18/laws-of-software-development/ _______________________________________________ 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. _______________________________________________