Upcoming secure development sessions
I’m speaking as part of a panel on secure development practices for Red Hat Developer Exchange and the Red Hat Summit. I work on the Red Hat Product Security Team, a group whose purpose is to help Red Hat develop products as securely as possible.
Quite often when people talk about software security it’s an afterthought. You write your software, then you worry about security later. This can work sometimes, but it’s also really expensive. Once you have a functioning product and customers, security issues will cut into your bottom line. The solution is not to have some sort of security development program, but to develop in a manner which also happens to be secure.
This is of course easier said than done. You can’t just flip a switch or read a book to suddenly develop software in a manner that can help avoid security flaws. It’s a lifelong effort, but it’s no different than learning new technology. The libraries we use today aren’t the libraries we used ten years ago. The security threats we face today aren’t the security threats we saw ten years ago, and won’t be the security threats we see in ten years.
At Red Hat we’re starting to think about this using a multi-phased approach. The most important part of this is to first build trust with developers, as much as I’d love to show up and start telling people how to do their jobs; I’m not qualified to do that, nor will they listen. Before we can work with groups, we need them to understand that we’re on their side, we’re competent, and we aren’t trying to create more work for them (we’re actually trying to create less).
Once a certain level of trust exists, what’s next is up to the project. Do the developers need some training? Do we need to use better tools to help improve security? Can we do more testing to catch some of these problems? Maybe we need better customer documentation to help them better use the product. The next steps really need to be tailored based on need, this is where things can get challenging.
If you’re involved in product development or just have an interest in security, I invite you to come to our secure development sessions. Bring your questions and ideas. Security is hard, there’s no magic bullet that’s going to fix everything. It’s often said the first step is just to admit you have a problem, then we can start thinking about how to fix it.
Come to Red Hat Developer Exchange on June 11th: http://red.ht/rhdevex