Developers Need Secure Development Training

Why do developers need secure development training as well as their regular training?

There is an old joke about 50% of doctors graduating in the bottom half of their class. It's kind of a sobering thought but it's true of all fields. The software development field has an additional burden in the fact that many developers come to the profession from other disciplines and never formally studied software development at all. They started programming for one reason or another and decided they liked doing so they stayed. Read some books, take a few classes, and start writing code.

They can do this in part because development is still more of a creative process than a rigorous engineering process. Many developers consider themselves artists. Developers are mostly focused on creating something that works. They take known processes and procedures and put them together in new and creative ways to accomplish their tasks. We are adding more engineering-type rigor to the process but we a long way from other engineering fields.

Most engineering processes pull known things together to create something new as well but in most engineering fields they are using things with known strengths and weaknesses and design things according to them. They use things designed to meet certain standards and if the standards don't meet the need another way is found or ways are included to compensate.

Engineers usually work with failure and limitations in mind and developers often do not.

This is where security training for developers comes into play.

In engineering, we've been doing things for a very long time. We've been building buildings for thousands of years and studied their failures. We've built bridges for centuries and have seen how they collapse. We've studied how well things hold up over time. We've learned to overcome those failures and reliability issues. Things still fail but it is far less common today. Those failure lessons are part of the education process of all engineers. Things still degrade but generally in ways we understand pretty well.

In software, we've been building things on a large scale for only a relatively short period of time and we've been exposing it to people determined to make it fail for an even shorter period of time. We do not have centuries or even several decades of experience in software failing. Since we lack that long history of studying software failure it has not been included in our general development training to any great extent. It's not a general part of what developers learn. We mostly learn what works, not how they fail.

Luckily there are experts who have made studying software failures a full-time job. We have learned a lot about common causes for failure both from the design perspective and from the implementation perspective. This knowledge is, unfortunately, not yet a common part of a developer's general education. To put this knowledge in the hands of developers requires training and we do it through teaching them to design software with security in mind and write code that avoids common mistakes that have plagued us in the past. It is why we say training is key to any software security effort.

In many ways, this is no different than other professions. Even in engineering where considering failure is part of the process, there are new lessons to be learned. Buildings and bridges still collapse. Those failures are studied and once understood the lessons are shared with the industry and engineers are trained on them. Doctors have to constantly learn how treatments are being refined and new things are being done. Training developers to deal with security failures in their products is no different than any other profession keeping up to date except that we only have a couple of decades of experience we are building on.

Why do developers need secure development training on top of their other training? We're still a maturing discipline that lacks a long history of learning from failure. We do not get much information about dealing with failure in our regular training so we have to provide it separately for now. Eventually, it will be part of the general education a developer receives like it is for so many other engineering fields but for now, we have to share the lessons of failure as we learn them.

Previous
Previous

Introduction

Next
Next

The Joys of Waiting for Tools Part II