Security inspection checklist

By Najaf Ali

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:

Check the Riding Rails blog for new Rails
releases and any vulnerabilities they fix. Upgrade or patch to mitigate.

Update brakeman scanner and run it on your codebase. Investigate issues it raises.

Grep for html_safe. Ensure that any found instances can't be used for
cross-site scripting.

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:

Exactly what the checklist consists of. You can use the above as a starting
point, but this might be different depending on your project.

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.