Why do developers need secure development training as well as their regular training? The answer to that starts with a side trip into the aviation world.
Have you ever wondered why the windows on commercial airliners have rounded corners instead of square ones?
In the 1950s when jet service was fairly new there were a series of crashes of de Havilland DH 106 Comets, the first production commercial jetliner. During the investigations into the crashes it was discovered that the hulls experienced metal fatigue, something that was little understood at the time, and could fail catastrophically. As the cabin was pressurized and depressurized over and over and encountered repeated changes in temperature while changing altitude it cause metal fatigue that weakened the structure. In some areas of the structure there were special stress points that experienced more problems than others. One of these special stress points were the corners of the square cornered windows on the original versions of the Comet. The square corners caused levels of stress two to three times greater than the rest of the fuselage. The metal was going to fail after a number of flight cycles with one of the crashes coming from as few as 900 flights.
The Comets were redesigned and had a productive 30 year career in civilian service and military variants were in use over 60 years after the first Comet’s flight.
Future jetliners were designed with round corner windows and with metal fatigue in mind. Early on these lessons were learned by practicing engineers by studying the failures of the Comets. Later on aeronautical engineers were taught about these type failures as part of their studies. Travelers today are safer for it.
Today’s software world is not unlike the early days of aviation. We try new things base on what we have done before. Some of these new things will succeed and others will fail. Some of the failures will result in security problems. These successes and failures create lessons we all need to learn. Developers naturally will tend to focus on the success and easily pick up the lessons from them. They are not quite as good at naturally learning the lessons from failures. Those lessons learned from earlier successes may not apply as our applications grow in size and complexity and are expose to new and changing environments. Those success lessons may lead us to failure as we encounter things we have not encountered before.
Luckily there are experts who have made studying software failures a full time job like those Comet investigators who discovered why those jets crashed. We have learned a lot about common causes for software failure both from the design perspective and from the implementation perspective. We have learned the common coding patterns that cause security failures we see all the time. We are learning the common design flaws that cause security issues. These common causes are lessons all developers must learn just like how aircraft designers had to learn about why early jetliners literally fell apart.
These lessons, unfortunately, are not yet a common part of a new developer’s general education let alone part of the education of those of us who have been writing code for a long time. Like those practicing aircraft designers at the time of the Comet crashes, we have to learn those lessons and apply them to our work in progress. We do that through secure development training. This secure development training takes the knowledge learned by those studying software failure and makes those lessons available to developers writing the code that runs our world today. We cannot just keep learning from the things that went right, we must also learn from the things that went wrong.
So like the aviation industry, as we push off in to new and unexplored uses for our software, we are going to encounter failure. Those failures can teach us lessons that will help us build better and more reliable software in the futures. Secure development training is learning from failure. Just as we no longer see jetliners with square cornered windows, we need to see software no longer vulnerable to SQL Injection and buffer overflows. It’s time we learn the lessons failure is trying to teach us.