3 actions you should take if your Ruby on Rails application has been around for more than 3 years

If your Ruby on Rails application has been around for more than a few years or so then here are 3 actions you should take.

What version of Ruby on Rails are you running?

First, what version of Rails are you running? The core team for Rails have committed to a maintenance policy which sets out how long features and fixes are provided for each version that’s released. At the time of writing (November 2018), the latest release is 5.2. It is the only branch that currently gets bug fixes, and this will continue until either 5.3 or 6.0 is released (spoiler alert, it highly likely that 6.0 will be the next main release). Security issues are only provided to 5.2 and 5.1 branches, while severe security fixes are applied to 5.2, 5.1, 5.0 and 4.2. If you’re running a version of Rails below that, you get no fixes at all.

There are a few things you have to consider here.

• Even if you’re on one of the currently supported versions, have any of these security fixes been applied when they were released? You can tell by looking at the final digit of the version number. So the current latest version is actually 5.2.1. If your version is 5.2.0, then you don’t have all the fixes and security patches applied. You can find the most recent version for each of the branches by looking at the versions list on the RubyGems site.
• If you’re on an unsupported version, then you should consider upgrading to a supported version. There are several advantages to staying up to date, and we’ll cover that in more detail later. If your application is stable and doesn’t require many changes but you do want to stay secure, then there is a third-party Rails LTS (Long Term Support) solution. They backport the security fixes from the supported releases and apply them to the older unsupported releases, and also add some extra security hardening features not present in the standard Rails releases.
• Whether you’re on a supported version or not, patches don’t apply themselves. Your developers can do this for you. We provide this to our clients through support and maintenance contracts, so the clients know their application is protected within a day of a security patch being released. This includes providing Rails LTS solutions to clients with older applications.

Action: Make sure you’re patched to the latest version of your Rails branch. If you’re on an unsupported version and security is important to you, consider upgrading or subscribing to Rails LTS.

What version of ruby is your application using?

In a similar vein, you also need to consider the Ruby programming language too. The current version is 2.5.3 with 2.6 on the horizon. It follows a similar maintenance policy to Rails where version 2.5, 2.4, and 2.3 are all maintained with security fixes. If you’re running version 2.2 or lower, you won’t be getting any patches issued to fix security problems.

You can see the latest versions and which are maintained or not on the Ruby downloads page.

One additional factor: The version of Ruby on Rails you’re running has specific ruby version requirements so you may find that to be able to move to a supported ruby version you will need to either upgrade Rails or subscribe to Rails LTS. (Rails LTS versions work with ruby 2.3).

Action: Review the version of Ruby you’re using and have your developers/ops teams confirm that your Rails application runs using a support ruby version. We recommend testing the application on a separate test server first before rolling out changes to your production environment.

Hosting environment

The next thing to consider is your hosting environment. Has it been looked after and upgraded since your application was developed? Software never stands still. Just like your own personal computer, the server(s) your application runs on must be maintained and updated too. If your application was developed in, say, 2012 your server might be running the supported operating system of that period. Now, in 2018 it will no longer be supported and receiving patches for the various other components of your application, e.g. your database, mail servers and web servers. Again, have your development/ops teams been taking care of your hosting environment for you? Have they ensured that when there is a security patch released for the web server software or database that it is applied promptly to protect you from security vulnerabilities?

Most of the above will apply to the more “traditional” hosting environments like shared hosting services, or you’re own physical or virtual servers. And if your application was developed several years ago, then this is quite likely to be the hosting used. You may be using a more specialist service, such as Heroku. In this scenario you need to look at the specific stack you’re running. If your application is relatively old and hasn’t been maintained, then you’re probably running on the Cedar stack. Right now, this is deprecated but supported until April 2019, so you have some time to consider your options and upgrade to a newer stack. It is likely that code changes will be required.

Action: Review your hosting environment operating system or stack and determine if it’s still supported or not. Ensure that all security patches are applied and will be applied going forward. Come up with a rolling plan of maintenance and upgrade to ensure your hosting environment stays secure.

Foxsoft has been working with Ruby on Rails since 2006 and have the experience and knowledge to help you get your application back on track.

No matter how much, or how little help you need, Use the form below to get in touch or give us a call.