Secure Coding mailing list archives

Where Does Secure Coding Belong In the Curriculum?


From: list-spam at secureconsulting.net (Benjamin Tomhave)
Date: Tue, 25 Aug 2009 08:35:20 -0700

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
falcon at 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/


Current thread: