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.
- Grep for
permit. Check that parameter white-lists protect against mass assignment vulnerabilities.
- 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
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.
- How often you expect the checklist to be run through.
- Who's responsible for walking through the checklist.
- A date and name for each inspection and what it uncovered.
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.