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:

• 3 team meetings at Drupalcon Chicago, Drupalcon London and Drupal Denver
• 3 core security releases in 2011 compared to 2 in 2010
• 59 contributed project security releases in 2011 compared to 113 in 2010
• 137 issues created on our private issue tracker in 2011 – security.drupal.org
• 1645 comments created on those issues on security.drupal.org in 2011 (including automated comments)
• dozens of issues were reported to the team and became public issues because they are not supported in our private process

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 security@drupal.org 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.

• Added a CCK content type for the creation of Security Advisories and a tab that formats this information so it can be pasted directly into the post on drupal.org. This provides contextual help to project maintainers as they create the SA and reduces the time spent writing the HTML for the advisory.
• Comment ACL was deployed to security.drupal.org, allowing the team to invite the issue reporter, project maintainer, and interested parties to help work toward resolution of issues in the private queue without seeing other security isuses. This fixed the number 1 slow point in our process (discussion on a mailing list and individual emails that had to be relayed back to the security issue queue).
• We added a Content Type for creating security advisories and added a custom callback to format the results for copying/pasting into the announcements on drupal.org. This removed difficulty from the second most manual and cumbersome part of the process.
• Created and added the Project Issue Availability module which helps us know which of our team members should be assigned to which issues AND how many issues they should be assigned to.
• Improved the submission process so that all logged in users can now submit issues directly instead of emailing! More on this below.
• For logged-in users, the homepage of security.drupal.org shows a “dashboard” of issues that need attention. This makes it easier for security team members who have limited time to give to the team to find what they need now.
• When a user is granted access to a private issue on security.drupal.org the site now subscribes them to notifications for that issue and sends them an automated email with instructions on what to do next.
• All users were subscribed to notifications for issues they had access to, reducing manual effort in mailing people.
• Updated documentation pages including updates to the team overview page, how to report an issue and what a project maintainer needs to know to work in our process.
• Changed our process to start getting CVE identifier values for vulnerabilities in core security releases. This is a bit of additional coordination but is hopefully useful to system administrators and security researchers.

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.

• Michael Hess (mlhess) a faculty member at the University of Michigan who asks his students to review Drupal for security issues
• Matt Kleve (vordude), a site-builder and developer for Lullabot
• Forest Monsen (forestmonster), web infrastructure and security specialist for National Service Resources & Training
• Chris Hales (chales), DevOps Manager, Lead Architect at Mediacurrent

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.