Keeping vulnerable dependencies out of your Rails App

Not a single day passes without news coverage of yet another security incident. That makes it clear that writing secure code is an essential skill for software engineers these days.

This is the first post in a 3-part series that explores using open-source tools to level up the security of your Ruby and Ruby on Rails applications.

When writing software we try to avoid functional bugs. We write unit and integration tests so ensure our applications and code work as expected. Sometimes we write code that functions the way we expect. However, that code may introduce significant security issues.

Let us explore at some tools that allow us to detect security issues in our code. Following the instructions in this series will bring your applications up to a decent level of security testing. No matter if it is a new codebase or a 10-year-old project.

The open-source tools that are discussed in this series can be used to extend your regular work-flow or standalone to asses the current status.

In this series we will look into:

To run the security tools based on the instructions, you do not need a CI pipeline. However, it is generally recommended to have one in place so you get timely feedback on your code changes.

This article will focus on bundler-audit.

Bundler-Audit

Bundler Audit falls into the category of software composition analysis (SCA). According to several sources, modern applications consist of 80-90% of open-source or third-party libraries. Ensuring that your dependencies are free of known vulnerabilities is a key security requirement. Bundler-audit detects vulnerabilities in the libraries that make up your application.

SCA tools create reports that typically include:

  • The package name of the insecure dependency.
  • A severity of how bad the known vulnerability is. This usually ranges from none to critical.
  • The minimum secure version you should upgrade to.
  • References that explain what the problem is.
  • Identifiers that point to public vulnerability databases.

Enough theory, let’s get started! First, add the bundler-audit gem to your Gemfile and install your bundle:

gem 'bundler-audit'

Now you can run the following command:

bundle audit check --update

This will first update the local bundler-audit database and then check your project for vulnerable dependencies.

Keep in mind that running bundle audit does not update your dependencies automatically. It’s highly recommended to always update the local database before each run to get up-to-date results.

To enable the rake tasks, add the following to your Rakefile:

require 'bundler/audit/task'
Bundler::Audit::Task.new

A rake bundle:audit will now update the data and perform the checks.

If you found any vulnerabilities at this point do not be worried. You can look into fixing them by updating the affected Gems to the next safe release.

In case that there is no update available use --ignore $vulnerability-id to suppress the alert for the time being. Make sure to check periodically to see whether a fix has been released.

For example:

bundle audit check --update --ignore OSVDB-108664

The output looks something like this:

output bundler-audit run

Congratulations, you now have a better understanding of your dependencies and can identify security issues quickly.

Fixing Findings

When vulnerable dependencies have been identified you need to assess what your next steps are. By looking at the severity you can get a good understanding of the urgency of the issue. Quite often you will run into low severity findings in a development dependency. This is what we consider as noise at GuardRails and it won’t require any action from you.

It is a good practice to update your dependencies to the latest version regularly. With this approach, we avoid being far behind in the case of an emergency upgrade. Upgrading bug and minor versions usually works without a problem. However, having to upgrade a dependency to a major version, while being under pressure to ship, can be very frustrating.

Sometimes a vulnerability is reported, but there is no security fix available yet. In this case, you have to understand how the vulnerability could affect your application. Identify where and how you are using the library and try to mitigate the risk with your own hotfix.

Finally, another option is to replace the insecure library with a safe alternative, if possible.

OWASP has excellent resources on dealing with vulnerable dependencies, which can be found here.

A Better Way

If setting up bundler-audit for your repositories and checking for false positives sounds like a lot of work to you, then give GuardRails a try. GuardRails fine-tunes and filters the results for tools like bundler-audit, so you can focus on shipping your product. You will be notified in your pull request when new vulnerabilities have been detected that require your attention.

try guardrails