Eleven tips to keep Drupal up to date with security releases

Keeping your Drupal site up to date has always been of critical importance to ensure it remains secure. Last month's announcement of a SQL Injection vulnerability and subsequent announcement of automated attacks within 7 hours caused wide spread panic across much of the Drupal community.

Here are eleven tips to ensure your modules and core code are up to date with the latest security releases.

1. Follow security news

If you are not already following Drupal security news, it is time to start now. This is how you get alerted to security updates as soon as they are announced.

You can get security advisories from these places:

2. Check update report regularly

The update report (available here: admin/reports/status) will alert you to problems with your Drupal site, including security issues such as out of date modules, Drupal core or database updates that need to be run.

You can get notified when updates are available by adding your email address here: /admin/reports/updates/settings

Pro tip: for performance reasons, it is better to have the Update Manager module enabled and running on a dev or staging site than the production site.

3. Apply security patches asap

When a security update is announced, apply it as soon as it is humanly possible. In the past, we had a day or two to apply updates and still be safe. With larger companies, deploying an update needs to fit into a regular deployment timeline, so it could take many days or even weeks. That didn't used to be much of a problem. It is now. The first known attack following the Oct 15th security advisory happened within 7 hours. This meant that you only had 7 hours to update and be safe from potential attack.

So be ready every Wednesday. I've put a recurring task in my todo manager for every Wednesday.

4. Use Drush to update.

You can download Drupal core and modules from drupal.org and manually apply them to your Drupal codebase. This gets tedious very fast. To make this a painless experience, you can use a couple of Drush commands instead.

Check what has changed

pm-update --pipe (alias: up --pipe) - lists projects that need to updated. You can then go and check the release notes to see what has changed. [Thanks to James Oakley for this tip]

Run the updates in one step

drush pm-update (alias: up) - update Drupal core, modules and themes and run any pending database updates

Run the updates in two steps

If you'd rather not run pending database updates at the same time as updating the code, you can run these two commands instead:.
* drush pm-updatecode (alias: upc) - Update the code
* drush updatedb (alias: updb) Run the pending database updates

You should not run these commands directly on the production site. Instead, run them on your local version (or another dev version) and ensure nothing breaks before applying to the production site.

5. Don't hack contributed modules or core code.

It maybe quicker to make changes to contributed modules or Drupal core, but this leads to a long term nightmare for keeping your core base up to date. If they are left untouched, upgrading is a painless experience. If they have been altered, you will lose any changes when you upgrade that you will need to re-apply.

6. Check if your contributed modules or core code have already been hacked

If you didn't develop the site yourself, you may not know if someone else has hacked contributed modules or Drupal core. Fortunately, you can easily check by using the Hacked module.

Hacked is a great utility module which will check if your contributed and core modules have any differences to what is stored on drupal.org. Checking this will see if anyone has meddled with your code.

7. Create patches for hacked contributed modules or core code

If, after running the Hacked module, you discover that someone has altered contributed modules or core code, then it is best to store these changes in a patch file. Then when you need to update your Drupal install, you can re-apply the patch file. This will save a lot of time as opposed to manually re-applying the changes.

8. Backup your database automatically

It goes without saying that you should be running database backups automatically on a regular basis. For more information, check out my recent article on backing up to Amazon S3.

9. Check your backups are working

Automatic database backups are great, but what if they are not working? It is a good idea to periodically restore them and make sure everything is in order.

10. Have code in a version control system

Storing code in a version control system (such as Git) is great for a variety of reasons. When you apply security updates, you can see exactly what has changed if your code is stored in source control. This makes it much easier to ascertain the potential risk of the update breaking your site.

It also provides you with a method of checking if your site has been hacked because you can check for differences with the code stored in version control.

11. For clients: Pay for a quality security and maintenance contract

If you don't have time or knowhow to keep it up to date and secure, seriously consider paying for a maintenance contract from an experienced Drupal consultant, or agency.