This brings up a great point. How can we grade a program's security level? Is it just a checkoff list? Which elements should be in that checkoff list?
The worst part of teaching is grading papers (programs are a close second). Making that more complicated is not likely to work. I already spend more time than I want on it, how are you going to convince me to spend more time looking for "secure programs"? It won't happen.
(10 seconds grading would be too long, so "enough time" is a relative rather than an absolute time.)
This also ties back to what things you can really look for in most instructional programs, though this would depend on the level of the class. Still, if you are going to require a solid mathematical algorithm, you had better have spent some time going over how to implement mathematical algorithms in code. In the same way, if you want a student to check against SQL injection, you have to have taught that at some point. (Neither have to be in the same class, but they must be prerequisites and likely part of a lower level class.)
Curious question: How many proclaiming "weave it into the curriculum" have worked with many lower-level classes as an instructor?
-- Brad Andrews RBA Communications CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI Quoting Rob Floodeen <flood...@gmail.com>:
2. a formal method for deducting points from a properly working but incorrectly constructed program (a "Show your work" secure coding equivalent)
_______________________________________________ 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. _______________________________________________
