Recent events such as Drupalgeddon in October 2014, and other releases have shown that security is an important part of the Drupal community. Drupal is also one of the few open source projects that has documented processes in place and a dedicated security team which coordinates fixing Drupal, its modules (plugins) and themes when security issues are identified.
Recently, one of my own personal servers became compromised (thanks to an old WordPress install that I had forgotten about), and I had to go through the trouble of retrieving all that data from backups (the server was running about 10 different small sites), re-imaging the server and re-deploying everything. Needless to say, it wasn't a fun situation for anyone.
This is why I'm so happy with the way we prioritize security at Mediacurrent. We make sure every site we maintain is up to date in every way possible. That includes core Drupal files as well as any installed contrib modules.
The reason we can do this is that we follow best practices that include not “hacking” or modifying any core or contrib modules to achieve results, but instead implementing overrides through custom modules, configuration, or contributing patches back to the projects individually. When patches are required, we make sure they are documented inside each project so any future developer is aware of changes that exist when making updates.
How To Keep Your Site Up To Date
Be on the lookout for both core updates (for example, a new Drupal version 7.39 is available while you're running 7.38) as well as contrib module updates. Instructions for applying them are described below. Make sure to backup your site's database and codebase first - ideally the code should already be in source control using something like git.
Check details on the severity of the update to determine how quickly it needs to be patched. This blog post gives a great overview of the different security implications and how they might affect a given site. For example, if an exploit can only be performed by a logged-in admin user with permission to create rules, it may not be as critical for you to update as one that can be executed by any old anonymous user.
Your site probably uses a number of these, and they release updates for functionality and security fairly often. You can keep up with security releases in a number of ways:
- Subscribe to the Security Mailing list on Drupal.org
- Add the RSS feeds for core, contrib, or public service announcements
- Follow @drupalsecurity on Twitter
For a visual look, you can enable the Update manager (update) core module and use it to check which modules have updates available:
A trick I like to use to save time after getting the names of the modules is to head to the command line and run “drush upc module_name” on each one, and then run “drush updb” to install any database updates they might have.
Another thing to note is that significant changes can exist in major versions of a module, and may cause issues when upgrading. Security releases will be in the same branch (i.e. 7.x-2.8 to 7.x-2.9) so make sure you are not jumping from a 7.x-2.x release to a 7.x-3.x release for example.
When a new major Drupal 6 or 7 version is available, you can obtain the latest code by downloading the Drupal source or by checking out the 6.x or 7.x branch of the Drupal.org repository. Again, make sure to backup your site's database and codebase first!
To bring core changes into your site, copy over every file and folder in the root directory except the “sites” folder which should contain all your site's custom configuration. Keep in mind to look for any changes to files like .htaccess, .gitignore, and any patches that have been applied to the current version of Drupal you're running.
Lastly, always test these changes in a local, dev, or staging environment to ensure new versions aren't breaking any site functionality. Good luck and stay secure!