Five months after a Ruby on Rails vulnerability is identified, announced and fixed in double-quick time, there are still applications running on public servers that haven’t got that memo. This was a very well publicized and well known exploit, yet not everyone knew about it.
What happens if you’re running a Ruby Gem that isn’t so well known, how would you find out that there’s a problem that you need to take care of in your application? You could follow the twitter stream of the writer of all your Gems. Good luck with that!
The very best way is to follow all the relevant security updates from the National Vulnerability Database and filter out which ones apply to your application. This sounds like a full time job, and you have better things to be doing with your time.
Do you really know all the Ruby Gems your application uses? Not just the ones you explicitly added to the Gemfile, but the ones that those Gems required as a dependency? Bundler does provide a nice file - Gemfile.lock - that includes all of the actual Gems used by your application, but have you ever even opened that file?
Do you only have one Ruby on Rails application? No - you have several. I don’t know anyone who only has a single Rails application. All the above problems multiply with the number of applications you are maintaining (even if you don’t do anything to an app, if it’s running in public, you are maintaining that app!)
With these problems in mind, I’ve started development on a new SaaS application called RubyAudit.
RubyAudit will protect your application from two scenarios:
- New vulnerabilities found and reported
- Vulnerabilities created by changing your application to use a different Gem version.
I am in the process of developing this application, and it should be available shortly. Sign up at RubyAudit to get updates and to be one of the first people to get Gem vulnerability protection for their Rails and other Ruby applications.