Dries Buytaert

Throughout the years, Drupal has taken a leadership role in the open source community on how to handle security releases — we were one of the first open source CMS projects with a dedicated security team and, even to date, our security processes lead the industry in transparency and responsiveness. We set an example for other projects, and that is something we can be proud of.

Initially, the security team created releases as soon we were able to — sometimes it took hours, but at times it took 3-4 months. As the number of contributed modules grew, though, so did the work of the security team. We then switched to bi-monthly releases. Regular, time-based releases proved to be a smart move — it allows for better planning and coordination which increased our throughput. The security team has made a big leap forward; so far, we're keeping up with the workload, but only by the slimmest of margins.

Last year, the security team supported 2,000 contributed modules; today we support over 4,000 and that number grows each day. In the past, as Drupal grew, we recruited more and more people to help with the increased workload. While this strategy has worked so far, the reality is that it won't scale forever. Drupal is a volunteer project and as a result, (1) no one is going to step up and spend a few days each week coordinating the security team, and (2) no volunteer contributor likes to be coordinated to begin with. It is key that we accept that.

For the security team to transition to the next level — and to avoid being overwhelmed — it must redefine itself. Our primary goal should be to establish a team that is designed to scale: a team that can handle more work in a healthy, fun and timely fashion. Addressing vulnerabilities should become our secondary goal. Let me explain.

I think our path forward is this: first, focus on creating security tools that are available to all developers, and integrate these tools seamlessly into the developer work flow. For example, instead of having the security team write all security advisories, provide module maintainers the tools to author their own, through the release management interface, within guidelines established by the security team and enforced with code. Secondly, once the tools are in place, the security team must focus on educating people about how to use them, on creating security best practices, and on holding module maintainers accountable for taking security issues seriously. There is a big role for the security team after the tools are in place, but personally fixing security vulnerabilities should become a secondary goal.

In other words, the security team should consider how every module maintainer can become responsible for managing their own security issues and publishing their own security advisories. By distributing the workload, we scale the security team to work within any size community, and we move the security team — and Drupal's security model — to the next level.

This is a good example of what I talked about in my DrupalCon DCDC keynote presentation: "Change planning with coordination" (Clay Shirky). The good news is that various people on the security team understand this, and several people have already committed to working on it.