Happy Bear Software

Security inspection checklist

Ever visited a well-kept restroom? You might notice an inspection sheet attached to a wall. After inspecting the toilet and cleaning it, you update the sheet with your name and the date.

Over the course of a given month, the security profile of a Rails application can change drastically. Inexperienced developers might be committing trivial security errors into the codebase. A serious vulnerability in one of your dependencies might have been reported. There are many more ways that security problems can crop up in your code.

For lack of more time to do security-oriented code audits, a regular security inspection by someone on your team is a good last line of defense against the most obvious security flaws.

Inspection check list

Here's a what a monthly inspection for a Rails app might entail:

  1. Check the Riding Rails blog for new Rails releases and any vulnerabilities they fix. Upgrade or patch to mitigate.
  2. Update brakeman scanner and run it on your codebase. Investigate issues it raises.
  3. Grep for html_safe. Ensure that any found instances can't be used for cross-site scripting.
  4. Grep for permit. Check that parameter white-lists protect against mass assignment vulnerabilities.
  5. Spend a fifteen minute timebox on observing the changes since the last inspection and attempting to identify any obvious security vulnerabilities.

There's nothing advanced or novel in this checklist. It won't protect you from advanced or novel vulnerabilities. Done regularly, it will however prevent the most easily exploitable security flaws from creeping into your codebase.

Running the checks

Keep a SECURITY.md file in your codebase and document:

An example of what your SECURITY.md file might look like.

Resist the urge to automate

For whatever reasons, developers dislike the manual work of assessing a codebase for security errors. I don't want to speculate as to why that is, it's simply what I've observed on one development team after another.

Do this by hand for three months before you attempt to automate it. At that point you'll know whether or not it's possible to script it away. You'll probably find that the most insidious vulnerabilities only get fixed when there's a human actively looking for them.