Last Updated on November 20, 2020 by Christopher G Mendla
During my interviews in my recent job search, I’ve seen an alarming number of companies running on Rails 3.x and 4.x. Unless serious work arounds have been applied, these versions have multiple vulnerabilities.
Overview – why it is important to keep as current as possible with your Rails version
Any software goes through a continuous process of improvement. New features and functions are added. More importantly, security issues are addressed. Ruby on Rails applications have four major areas where they can be exploited.
- Ruby – The underlying Ruby version needs to be at a version that does not have vulnerabilities
- Gems – Gem updates are critical to the security of your Rails application. Gems need to be constantly updated
- Supporting applications – Applications that are installed on the server such as Yarn need to be updated when vulnerabilities are discovered.
- Rails – Your rails version needs to be at a version that does not have vulnerabilities.
As of November 2020, Rails versions prior to 5.2.4.4 have an actionview vulnerability that must be addressed
Let’s talk about Rails in this post
For this post, we will concentrate on vulnerabilities in Rails.
As of November 2020, Rails should be at 5.2.4.4
I just spent a couple of days updating my rails profile site to 5.2.4.4. GitHub’s dependabot was showing a notice that there were vulnerabilities in my code.
Working through the notices showed that there was a vulnerability in actionview for Rails versions prior to 5.2.4.4. The notice did mention possible work arounds. However, the cleanest way to fix the situation was to upgrade to 5.2.4.4. That turned out to be a bit of work as the upgrade to Rails 5.2 is a little involved.
An alarming number of companies are still running Rails 3.x or 4.x. That almost certainly means there are vulnerabilities in their application.
Rails versions prior to 5.x are UNSUPPORTED
As of November 2020, if you look at the Wiki for Rails, you will see that versions of Rails prior to version 5 are unsupported. That means that any vulnerabilities in those versions are not being fixed. That is a hacker’s dream. Another good resource is cvedetails which will show all the vulnerabilities for Rails.
Why would a company run a production site on a vulnerable version of Rails. ?
Updating is blah, menial and not sexy.
There are a number of possible reasons. Doing ‘mundane’ update work just isn’t sexy. In a previous position, upper management was critical of our team because we weren’t “Putting out enough new features”. The team was an Operations and Maintenance team. Each of us had four production apps to maintain as well as doing bug fixes and some new development.
The accolades went to the teams that were developing new applications, not to the O&M team that was keeping the applications secure.
In a previous position, members of our team were criticized for “Spending too much time on updates and maintenance” even though the constant integration system would preclude builds if the apps were not updated. Management wanted to report new features.
Management doesn’t want to make the commitment or expend the resources.
Maintaining and upgrading applications takes time, money and resources. For a company that is on Rails 3.x, the prospect of moving toward the current version, 6.x at the time of this post, is daunting. Quite often, the development teams are in a Dilbert like world where the pointy haired bosses don’t understand the necessity for keeping current.
Major upgrades are risky and, at times, difficult.
A major version upgrade of Rails can be time consuming and poses risk. In many cases, supporting applications such as Postgres or the Ruby version might need to be updated.
A number of Rails updates I have done have either broken Rspec tests or required changes to the gems and applications that support Rspec.
How to keep an eye on vulnerabilities
If you are using GitHub, the ‘dependabot’ feature will alert you if your master branch has vulnerabilities.
Keeping up with Rails versions
The team should have a plan to constantly be upgrading. Letting the version stagnate for a year or two because you didn’t have the resources or because working on updates didn’t put the developers on a promotion path will cause problems later.
Second or third best is OK.
It isn’t necessary to always be on the latest version. There is risk to being an early adopter. Set a target perhaps for being no more than two minor versions behind the latest stable version.
Major vs Minor
In general, updating to the next minor version is usually straightforward. There are exceptions such as updating to Rails 5.2
Updating to major versions usually requires more work and poses more risk.
Summary
Updating Rails isn’t sexy or career enhancing but you need to keep ahead of any vulnerabilities. Establish a plan and be sure that efforts to update the code base are rewarded and not punished.
