How can I stay informed about Drupal security updates?
Resolution
Staying on top of updates to Internet software is a big responsibility. It's critical to the security of your website and yet can take a lot of time. The traditional advice about updates is to subscribe to the updates mailing list: that works well for most projects.
For broad software projects like Drupal, however, that advice is increasingly unmanageable. Drupal update emails cover not just Drupal core, but also many of the contributed modules, themes, and distributions available on drupal.org —over 20,000 of them. Any individual website may have 50, 100, or more. So, if you sign up to get emails about security issues across 20,000 modules and you only care about 200 of them, the chances of getting a message about a module you don't need are very high.
Here are some ways you can receive updates; see which one is the best for you.
Method
Pros
Cons
Enable the Update core module with security focused settings (configured at Administration > Reports > Available Updates)
It's a focused report to your needs on your website.
It can be sent to multiple inboxes, including a ticketing system or support team.
This relies on the cron mechanism. In Drupal 7, you can either set up cron to run on your server (for example, using crontab), or it runs using the so-called poor man's Cron, which runs periodically after a page visit by a website visitor. If Cron isn't working, this won't work for you.
If email from your server isn't working, then this report won't be delivered to you.
It can negatively impact performance. We recommend using it on test environments because the production server shouldn't need to spend time and resources on polling drupal.org.
You get all the important information as soon as possible.
It can can help give you an idea of trends in issues; for example, CSRF is less common now than it once was, and seeing the advisories helps you realize that.
It has an overwhelming amount of information about core and all other projects, which is very likely more than you need when managing your specific websites with specific modules.
It's formatted for easy import into systems (for example, ticketing systems) that can import from RSS.
It can be paired with a tool like If this then that to trigger other events. These events could include scripts to start automated testing of a new build, email alerts, and so on.
For personal consumption, it may get lost among other RSS items.
The /contrib feed still shows information about projects you may not need.
Drush is highly customizable for integration with other systems.
It's very specific to the needs of your websites.
If you're monitoring with a tool like Nagios, it could create an alert if there's no data at all (for example, to prevent problems with cron not running).
Drush requires special access (that is, SSH) and some extra work on the server.
