Secure Programming: An Afterthought.

2 min read
February 13, 2019 at 1:00 PM


I’ve been a professional programmer for nearly 16 years. I didn’t learn to program in college, the military taught me. It wasn’t until my seventh year that the security of the applications I was working on was taken seriously. That is seven years of code that was more than likely vulnerable in one way or another. Eventually my career took a security focus and I was absolutely blown away with how common security mistakes are in the field. It was like seeing the trees in the forest for the first time.

When you’re new to programming, the magic of making something from nothing engrosses you. It never really dawns on people that the magic they are playing with is obscenely dangerous. One or two mistakes in a program with one million lines of code is enough to ruin someone’s life. We, as programmers, can take for granted the data that is handed to us. We are obsessed, like most programmers, with how that data is moved and manipulated to create something brand new. We don’t always take the time to think about the importance of that data. More than one program you use daily can easily contain enough data for a social engineer or criminal to steal your identity.

Things are getting better. Secure programming, secure application development life cycles, and penetration testing are becoming more common, but are in no way pervasive. DevOps is morphing into DevSecOps. But… this development is putting the cart before the horse. You wouldn’t teach your child to drive after they are driving.

The only real way forward is for the industry as a whole to require our novice programmers to understand security before they ever check-in their first bit of code. I want to see Secure Programming classes being mandatory for every Computer Science (programming focus) degree. I want to see companies sending their experienced developers to remedial training courses. I want to see static code analysis built into every. single. check-in. I want to see programmers and the companies that employ them held liable for the damage they cause with shoddy code.

After all, the only way to affect change is to hit people where it hurts: in their wallets.

Contact Us

Get Email Notifications

No Comments Yet

Let us know what you think