http://static1.1.sqspcdn.com/static/f/702523/26890568/1456888603297/201603-Cook.pdf?token=0f54EHOm9BNwSNhf3UAOmWk1mjs%3D

Check out this article from the March/April issue of Crosstalk.  As is my custom, I start from the back with BackTalk – usually a short somewhat pithy commentary (General written by David Cook of Austin State University) on software related topics.  In this issue David starts with a stroll down memory lane – his own personal journey into software engineering – beginning back in the days when we when coded using cards or paper tape or connected to a mainframe via a 300 baud modem.   The point of the article was Security and Defensive Coding – he started with the history lesson to highlight how far we have come and how problematic writing code that can be compromised has become as the reaches of the internet.

Having traversed a similar path as David into the world of Software Engineering, lots of his points about defensive coding really resonated with me.  He speaks of a Software Engineering course he teaches where the first assignment involves writing a program that reads in three numbers from a user supplied file and adds them together.  Sounds pretty easy right?  Until you consider the fact that the requirement is that they write a simple program that David is unable to cause to crash.  I don’t know how many of you reading this studied software engineering or computer programmer but I know when I had programming assignments, I concentrated on the go path, not taking time to build input data validation or other security features – because the go-path was all that was required.  Now to be fair, I did this before software development was considered an engineering practice, so maybe that was a reason why best engineering practices weren’t part of the curriculum.  But clearly the world has come a long way since I first learned to program (in Fortran!) and as the world and all of our computer systems get more and more entwined, it is imperative that quality code is a requirement, for anyone – student or employee – and that the best path is to code defensively!  David suggests that you imagine that all of the users of your code are terrorists intent on breaking your code to wreak havoc.