Where Does Secure Coding Belong In the Curriculum?

[bishop at cs.ucdavis.edu (Matt Bishop)]

Ben,

> Let's just hope that the code isn't compiled with -O3 or similar,
> creating an unintended bug. :)
> http://isc.sans.org/diary.html?storyid=6820

Brings back memories -- the first day on the job as a summer intern I  
had to track down a bug in a UNIX device driver. Turned out the  
optimizer was clobbering a jump -- the driver worked fine unoptimized.  
I quit believing tools like compilers were flaw-free after that!

> > Most people got it quickly.
> Getting it and applying it IRL are of course two completely different
> things. I still find it somewhat absurd that we even need to have this
> discussion still after how many decades of curriculum development? :)

Oh, I don't -- I think it's all too understandable. A story first, to  
provide some background.

One of my grad students (a security type, of course :-)) was my TA for  
the undergraduate operating systems class. We had the students form  
teams, and each team modified a kernel. The TA then graded  
interactively, asking the students about what they did and why, as he  
went through their code. My TA was appalled at the poor quality of the  
code of most teams -- it worked, but was not robust and was sloppy.  
So, he told each group that if they turned in code that poor the next  
time, he'd deduct 20% on general principles. So what do students do in  
that case? Right -- complain to the professor (me). I said something  
to the effect that I strongly disagreed with the TA, and felt he  
should have handled the situation differently; but since he said he'd  
only take off 20%, instead of the 40% I would have taken off, I'd  
support his decision. The students got the message. On the next  
assignment (and for the res of the class), the code was much better.

This suggests to me the problem is not so much a failure to teach  
robustness; in fact, I suspect most intro to programming teachers do  
mention it (although to different degrees of thoroughness and probably  
not using that name). The *real* problem is that we don't keep  
reinforcing it throughout the student's career.

And that's an artifact of a lack of resources for the type of grading.  
Give classes the support to do this, and I suspect you'd see people  
get in the habit of writing better code. Better, use students and  
people from industry who know this stuff to staff a clinic analogous  
to a writing clinic for English and law schools -- that would  
reinforce it not just for the students, but for the clinic staff as  
well.

Anyone who's interested in this idea can read about a small experiment  
I did in a paper at

http://nob.cs.ucdavis.edu/~bishop/papers/2006-cisse-2/

The results of having students use such a clinic, on a very small  
scale, led to some pretty good improvements in their code. The  
problem, of course, is that supporting such a clinic requires a lot of  
people time, and getting people to donate their time, or the resources  
(read: cash) to pay for it, isn't easy.

Matt