Drupal Security Team update – June 2012
This post aims to share information about the Drupal Security Team in 2011 and midway through 2012. The team processed a significant number of security advisories, added a few members, improved the free education materials in the handbooks, presented at dozens of camps and user groups, and made several improvements to our workflow (including some user facing changes, see below).
Some quick numbers:
You may notice that for the calendar year of 2011 there were fewer SAs than there were issues created. There are lots of reasons why that happens (mostly invalid issues or issues that affect versions not supported by our policy).
Improved security issue reporting process
This change is so exciting that it deserves its own section in addition to being listed below. The “Report a Security Issue” link on project pages now links directly to the security.drupal.org issue queue for that project. Using that link instead of sending an e-mail removes one of the final “copy/paste” jobs from the security team’s workflow.
We plan to always monitor email@example.com for issue submissions as well because that is a standard tool and we want to keep the barrier for reporters as low as possible. In January of 2012 there were 617 non-spam emails sent to that list and thousands of total e-mails which we have to moderate manually. So please remember: using the queue directly instead of emailing keeps us focused on our most important tasks.
Improvements to the team workflow
At events through the year like Drupalcon Chicago and BADCamp, several team members worked in sprints to improve the tools on Security.Drupal.org.
The Security Team process has historically been heavily reliant on email communication between the researchers reporting issues, the team, and drupal.org module/theme maintainers (see a recent high-level infographic on the team’s process). All three groups of people in that chain are volunteers who have other demands, so the e-mail communication was a common source of slowdown in progress toward issue resolution. While we created a private issue tracker in October of 2006 we were still reliant on private emails for much of the workflow. Many of the improvements below address this set of problems.
This work resulted in a number of positive outcomes for the team workflow.
This work required not only coding, testing, and deployment but also new documentation to help project maintainers to use it. These and other improvements to our workflow mean that we spend more of our volunteer hours working on the most valuable areas instead of manual tasks that don’t use the security team members special skills.
New members and role changes
As often happens, the team welcomed new members in the last year and a half. These new members had expressed interest in Drupal for several years and shown themselves to be good communicators who can be trusted with the confidential information that the team must handle.
During the year I (Greg Knaddison) took over as team lead from Heine Deelstra. Heine had been team lead for 5 years prior to that and stayed on the team as a member. Mori Sugimoto, Kieran Lal, and Matt Chapman continue in their roles as team coordinators.
I would like to re-iterate what I have already said to the team in private: Thank You! The job of the team keeps growing and growing and we are both working harder and smarter to keep up. If you encounter someone who is on the team I encourage you to thank them for their work. Security is often cited as a reason not to use Open Source software, so it’s important that we continue to have such a robust team working with effective processes so the Drupal project can continue to grow.
Comments are closed.