You often hear that training is a key piece of secure software development and it is. On the other hand, I like to flip things around a bit and point out that another key is overcoming our training.

It may seem counterintuitive but we have to overcome our training. Not our secure development training but a lot of our other development training.

Have you ever heard the old joke that half the doctors out there graduated in the bottom half of their class? We have the same problem in the development world but with an added burden. Not all developers studied computer science or any other related degree in college. They come to the profession from other fields where they learned to program for some reason and decided they liked it. But like doctors in that joke, half of us are below average when it comes to our training.

A lot of our training created bad habits. I like to quote a computer science professor of mine from back in the mid 80s. The lesson was not hard so some of us set off to add bells and whistles to the assignment. The instructor told us "Forget that extra stuff and just focus on the lesson." Translation, get it to work, and move on. Lesson learned and it wasn't good. There is a whole lot of get it to work and move on in the software world. When I gave a talk that touched on this at an ISSA conference a few years ago some members of the audience who were current computer science majors came up afterwards and said their instructors are still telling them to focus on the lesson and forget about the extra stuff. Bad habits still being taught.

Realistically what else can they do though? Lessons have to be tightly focused or you overwhelm the students. Add in too many requirements and grading become harder and more time consuming. I don't know that there is a good solution to this problem but when we are are instructors, we need to remind students that there is a bigger picture outside the narrow focus of the lesson. We must remember not to create bad habits in our students. When we are students, we have to remember there is a bigger picture beyond the immediate lesson.

Another part of our problem is our field is constantly changing. All too often developers may not have received formal training in the languages or frameworks they are using. What training they've received may well be out of date by time they need to use it. So we reach for a book, hit Google, look for answers on Stack Overflow. We look at examples to learn what we need to know, give it a try and if it works, we move on. All the while we forget the problem of narrowly focused lessons that leave out the bigger picture.

And what about those examples? Are they valid? Are they up to date? One of my favorite rants along these lines were the old database examples to teach developers how to do data-driven applications. Remember these old classic connection string examples?

strConnection = "SERVER=db.example.com; DRIVER={SQL Server}; DATABASE=northwind; uid=sa; pwd=;";

What is it telling you to do? Connect to the database as sa with a blank password. Not only is it telling you to connect as the database admin violating the idea of least privilege, but it’s also telling you to set the account to not have a password. "I don't know why we're supposed to do it that way but that's the way the example shows us to do it so there must be a reason!" Now anything that connection does has complete control over the server and anybody who can reach the database server directly has complete control with no password needed. Very serious security problems.

Or how about this to create a query?

mySQL = "SELECT * FROM tblBooks WHERE title like '%" & txtUncheckedUserInput & "%';";

Take unvalidated user input and put it into a query via string concatenation. Thank you very much for showing us how to create a SQL Injection issue in our code.

Today most database examples are no longer this bad but they used to be and those books are still out there sitting on bookshelves. With luck, they are buried under an inch of dust meaning nobody is using them anymore but we used to use them. The examples we relied on to teach us something new showed exactly how NOT to do database-driven applications. What are the examples we are following today telling us to do wrong? What if we don't know it until a couple of years from now?

So what should we do?

• If we teach, remind students there is a bigger picture and that the lesson is narrow to help them learn the basics.

• If we learn, remember there is a bigger picture than the narrow lesson.

• As we learn new things we have to remember the examples we follow are often simplified to be that narrowly focused lesson.

• If we create examples, remind those following them there is more to it than the code immediately in front of them.

• When we look at examples, consider their age. They may well be showing us things we now know are wrong.

• Get rid of those old books sitting on our shelves or if you have to keep them, make sure those who borrow them know they may not be safe.

Remember we have to overcome some of our training as we move towards securing our software.