&. |

Warning: I wrote this blog in 2015. That is a long time ago, especially on the internet. My opinions may have changed since then. Technological progress may have made this information completely obsolete. Proceed with caution.

I previously announced that I would be presenting at this year’s NCDevCon. Well, I tried! The conference suffered a complete power outage partway through the second day. I still tried to give my presentation in a dark room using only my laptop’s screen pointed at the attendees, but then we hit another snafu when a fire alarm cleared out the whole building.

As a result, I only got four slides in, and there is no video recording even of that part of the presentation.

I have put my slides and demo application on GitHub. You’ll find instructions there on how to set up the demo application.

One of the things I’m really disappointed that I didn’t get to discuss is Incentivizing Secure Code (slides 38-43). Here is the gist of what I wanted to say:

Our kneejerk reaction when we see insecure code is to say that the developer is ignorant or incompetent. But sometimes the developer is just making a rational decision to spend his or her time churning out as many features as possible, rather than spending more time doing something that probably won’t get recognized or appreciated (writing secure code). There’s often no incentive for the developer to make the code better. Given the rate of turnover in this industry, it’s quite likely that the developer who wrote the code for Target or Sony Pictures or Office of Personnel Management, or any other recent high-profile hack, is long gone from that job. They are not being dragged before Congress to testify. Their ex-boss’s boss’s boss is.

So, how do you solve this problem? Developers need to be incentivized to do the right things. I don’t mean monetary incentives. I mean the same kind of incentive you have to produce code that runs fast, or code that is stable, or a nice looking UI. Namely, that if you do those things well, you don’t have QA and product managers telling you that a million things are broken, and you have time to move on to your next task.

In my view, the best way to incentivize secure code is to train QA on how to test security. If the developer knows that security will be tested, and that QA actually knows how to test it, then he or she will be more likely to spend time covering security basics to begin with. In my company, we have a document that I worked with QA to develop, which provides guidelines for basic security testing. In a lot of cases it is as simple as “Enter <b>test</b> in every form field. If you see bold text, there is an XSS vulnerability”. Or “Enter a single-quote character in every form field. If you get errors there is a SQL Injection vulnerability.” QA needs to know how to use browser developer tools to modify hidden fields and select boxes.

None of this guarantees that your code will be secure. It should at least reduce very common and very preventable security vulnerabilities. There are other factors that are beyond the scope of this “101” level presentation. And sometimes it isn’t even in your control. It doesn’t matter if you won the Emmy for Best Coder last year; if you used OpenSSL you had a HeartBleed problem.