Saturday, February 16, 2013

Staying on top of Ruby on Rails security


Maintaining a Ruby on Rails application and keeping it secure might feel like a challenge with all the security attention that the framework has received recently. Here are my suggestions for staying ahead of the curve.

Read the Ruby on Rails Security guide - This guide discusses security best practices when writing Ruby on Rails code.

Join the Ruby on Rails Security Google group - Every patched Ruby on Rails vulnerability gets announced in this group.

Familiarise yourself with common web application security risks - The OWASP Top Ten is a great source for this: site and document.

Keep an eye on your popular gems for security patches - Devise, Rack and JSON recently had vulnerability patches.

Have an automated security scan as part of your build pipeline - Automated scans can not give you 100% confidence in your security status but it will highlight the most obvious flaws to you. Brakeman is a popular security scanner for Ruby on Rails that is easy to integrate with Jenkins.

Be ready to patch and deploy quickly - Be prepared to update and go to production at any point, be this on an application or infrastructure level. Adopting a Continues Delivery model will empower you to do this very easily.

Understand your application security threats and objectives - Threat modeling is a popular exercise to achieve this. It can be a formal process or a less formal process - the important thing is that you understand your application's security threats and objectives.

Have a security evangelist in your team - Give someone in your team the responsibility to take ownership of promoting security in your projects.

Other useful resources - Ruby Security, OWASP Ruby on Rails Cheatsheet

Wednesday, February 13, 2013

Successful pair programming interviews


We've introduced pair programming as part of our interview process at REA a while ago. In general I think its been quite a success. Its a great way to get a perspective on a candidate that you otherwise won't get. You see a bit of how they work first hand, instead of trying to infer it from a conversation.

The following is a list of things that I find helpful to get the most out of a pair programming interview.