SANS List etc..

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

As an academic who does teach this stuff whenever they let me in a  
classroom ...

> I'll address your third point.  I am ALL FOR teaching software  
> security at the university level (and have been actively working  
> with universities for over a decade).  I just don't think it is  
> realistic to try to push the problem off on universities and hope  
> that they will solve it.

WHOLEHEARTEDLY AGREE!!!!! Companies, purchasers, etc. have to help.  
The old saw of "working together" is, I believe, actually true. I have  
about 50 other cliches here that I could add, but I'll not bore you  
with them.

> As I have said, I would love to be proven wrong regarding my opinion  
> on whether adding software security to a curriculum us realistic.   
> For more on this, see page 98 of "Software Security" <http://www.swsec.com 
> > .

Hey, that's cool -- I forgot about the page. Thanks for the plug! At  
any rate, I do think it's realistic to add software security to the  
curriculum, but I think it's horribly *un*realistic to think that  
taking a class in it will solve the problems (and requiring students  
to take a class in it won't change that). You have to practice it,  
just like you have to practice writing.

> I do hope that academic programs will not focus on the bug parade  
> approach, however.  Building a course around the OWASP top ten or  
> the CWE/SANS top 25 would be rather silly.  I would rather see vulns  
> like this covered in every programming course and a software  
> security course focused on the touchpoints (especially code review  
> and architectural risk analysis).

I'd emphasize *why* these problems occur, and use the Top 25 list to  
explain what happens when you don't follow the principles. You can  
then show how to apply the principles to prevent (or at least limit)  
these problems. That will cut down on problems before code review.

And then you teach code review. You need to teach both how to do it  
right and how to catch problems when it is not done right, because I  
don't know anyone who *always* does it right. Perfection may be the  
goal, but it's not the reality.

> One thing emphasized by outstanding software security initiatives  
> (think Microsoft) is that teaching developers and architects how to  
> do things right is far superior to an after the fact analysis  
> approach driven by audit and regulations.

A very academically sound approach :-)

Matt