It’s one thing to know about SQL Injection, File Access Attacks, XSS, and other security hazards. And because you’re a great developer you’re regularly squashing vulnerabilities in your app. And yet every Ruby/Rails developer is relying on someone else’s code to do their work. And guess what? No matter how careful you are, no matter how much time you spend perfecting your code, someone else’s code is going to have a security bug (yours will too if you & I are being honest with each other!)
One of the questions that a few people have emailed me with now is: “How do I stay up to date on Ruby/Rails security?” It’s a great question! First because not enough developers care about security. Second because there are a lot of great tools out there to help protect your app. Let’s look at how you can stay up to date.
Follow Relevant Mailing Lists
The first step in keeping your app up to date and protected is to keep up with the news. The two main sources of security news are the Ruby Security Mailing List and the Rails Security Mailing List. Both lists focus on security and will give you the best warning that an attack/fix is coming down the pipe.
Follow CVE Reports
Now the Ruby, and Rails mailing lists are great, but you have A LOT more dependencies in your app than that:
nokogiri, rack, thin, puma, etc.. Unless there was a major issue in these gems they’re not going to make the
Rails or Ruby mailing list, so you need to get that information from elsewhere!
One of the little know resources for keeping up with security vulnerabilities are CVE databases. There are a few different sites that offer this type of information and CVE Details is my favorite because it’s easy to consume the information.
Keep Code Updated
A simple way to keep your application up to date with the latest vulnerabilities is to not let your dependencies
become outdated. To do this run
bundle outdated on your codebase and update the gems that are out of date.
This is usually easier said than done because updating dependencies can cause your application to break in unexpected ways. The mitigation for that is keeping your tests up to date. If you can update a gem, run your test suite, and nothing breaks (assuming >85% coverage), then you’re likely in a good spot to roll that dependency upgrade into production after some QA.
Put someone on your team in charge of tracking your dependencies (C libraries, Ruby gems, Python easy_install thingies) and have a process by which you periodically check to make sure you’re capturing upstream security fixes. You should run your service aware of the fact that major vulnerabilities in third-party library code are often fixed without fanfare or advisories; when maintainers don’t know exactly who’s affected how, the whole announcement might happen in a git commit.
I like this advice because it’s easy. Start by having a security day with your team. Buy some
and go through your
Gemfile.lock querying the CVE Details database and reviewing the
gem’s repository. Then triage any issues and schedule fixes.
Why get the whole team together vs one person? Personally I’m a fan of having the entire team involved in security since it creates a culture of good practices vs just a single developer.
The above processes sound cumbersome and manual (which some of it is going to be), so there are tools that you can leverage to automate this type of work for you.
Bundler Audit is one of the nicer tools. It uses the
rubysec advisory db to check for vulnerable gems in your
Gemfile.lock file, along with gem source issues. And it’s as easy as running the
This is a nice gem because it takes the research leg out of your dependency updating. And bonus points since it can fit in nicely as a CI build step. There are also paid versions that audit gem files as well like: AppCanary, Hakiri, and Gemnasium.
Why Stay Updated With Security?
Wrapping up, I want to emphasize that it is important to keep dependencies up to date. Security is sometimes a tough effort to justify because when it’s working you’ll rarely notice.
And with your apps security it doesn’t pay to be complacent:
Heard about a vulnerability? The adversary is not a stressed human like you. It’s a for loop. The vuln is not secret; after all, you know.
– Patio11 (Patrick McKenzie)