Secure Coding: Educating for Real World Problems

Software development is like any other discipline in life – you learn most effectively through your mistakes. Unlike a lot of other areas, however, in software development you tend to make a huge mess out of your codebase while you make those crucial mistakes.

Among the hardest problems in software are those you aren’t taught in academia. How to keep a codebase maintainable over time so that it can be evolved. How to work within a complex system in a way that minimizes risk. And yes, how to write code that is difficult for others to compromise.

The way the software lifecycle works today, those considerations often don’t get discovered until late in a product’s existence. Start-ups tend to attract young, inexperienced developers who haven’t had to deal with long-lived software. Consumers tend not to raise questions about security until after a product has demonstrated utility and longevity.

As a result, by the time your software company needs to take on architectural and security issues, you will likely have a daunting endeavor ahead of you. The good news is that your developers will be much better at their jobs by that point; the bad is that you’ll have years of mistakes to work through.

How do we, as an industry, overcome this dynamic? We need to start by introducing long-lived software concepts into the education system. Here are some classes I would love to see in colleges and even high schools:

Maintaining legacy codebases: this might be less of a class than an internal tool maintained by the computer science department. It would take a few years to get started, but by having students hand off the software each year would create just the kind of mess that students will often walk into on day 1 of their new careers.

Rewriting legacy codebases: the partner to the above class, this course would be all about learning from your mistakes, allowing students to re-design and re-implement the legacy codebase that they had been maintaining. Students would learn about issues like migrating users between versions, which always get in the way of major rework.

Serving up data at scale: forget about applying the latest big-data technologies. This course would be all about forcing people to think about how they’re going to validate scalability. Strategies for generating data, for simulating load, etc. If students can get to the point where they can assess how their solutions will perform, then they get to actually create a solution.

Compromising web apps: this class would be focused on giving the students the tools required to compromise anything exposed to the web. The most effective way to learn how to protect your own website is to learn how the attackers are going to go after it, first-hand. Is there danger in teaching people how to hack? I say no – after all, if they’re interested in being malicious, they already know how.

Protecting web apps: the partner to the above course, this class would provide the web apps for the earlier class to try to compromise. Students would need to take their applied knowledge of attacking to implement defense mechanisms. The goal would be to identify the handful of practices that, when implemented habitually, make at least the low-hanging fruit go away for attackers.

Social engineering: yeah – that’s right. Let’s teach people how to do it in a controlled environment. Let’s make them do it on each other. How better to prevent people from falling for phishing attempts than to have them design their own phishing attempts? This should be a required class for everybody, everywhere.

The exercises that a traditional Computer Science program takes students through are vital to their gaining approaches to problem solving. By adding a few real-life kinds of experiences that normally only show up late in the software lifecycle, we would better prepare our incoming employees to keep our code flexible and safe.