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.


Alexander Langer (not verified):

Sound like evolution. :)

Place responsibility back into the hands of those who always had it, but more often than not didn't know or didn't care about it - the module developers.

From my very own perspective it's mostly about not knowing what makes code vulnerable and how to get around it. When I thought and think of coding I think about problems and solutions, but not about security at first place. I've never been interested in hacking so I don't know much about how they do it, I just know some more or less basic concepts.

There's stuff like the Suhosin patch to PHP. It makes it more secure. How? I don't know, but
sometimes I have to tweak some settings when there's too much post variables in a web form :)

There's stuff like a PHP Safe Mode that does not deserve its name and will soon be history for good reason.

There's modules like the PHPIDS integration module that most Drupalistas don't know about, but may be of good use on shared hosting environments (haven't used myself by now) and there's stuff like the ModSecurity extension to Apache that I use on each and every of my root servers that even less Drupalistas seem to know about and that requires some of its core rules to be turned off depending on the used web apps. There may be a lot of unused security potential in ModSec if someone has the skills to hand write Drupal specific rules - too geeky for me. But maybe worth taking a look at for some pros out there?

Giving us advice / documentation / sharing knowledge on how to write secure code and tools to make work on security easier - very wise decision! It will make it easier to get started with dealing with security on our own and over time will lead to a lot of coders with experience and lots of robust and high quality code.

Hackers have their tools, now the empire strikes back...

Micah Tapman (not verified):

This is the type of work that my company is looking to provide to the community. We've recently started some research on automating the detection of common problems within modules using basic scripts to identify coding mistakes. The next step is to make the scripts (relatively) easy for module developers to use, and perhaps to setup a periodic and automated scan of the code repo to alert module maintainers of possible problems.

Another key area is the secure configuration of a Drupal site. This is much more complex than code review and depends heavily on the business needs of the site, ranging from open collaboration models to e-commerce sites with serious confidentiality concerns. Setting forth guidelines for secure installations is a good first step, however, these guidelines will need to be interpreted and that takes lots of training and experience to figure out.

Some of the easy things we could do include building more robust security controls into core, or providing semi-official support for key security modules in a similar manner to CCK and Views. For examples, password complexity filtering is a minimum standard for any site that wants to identify users, however, this is currently only provided through a contrib module.

TYPO3 Security Team (not verified):

Reading this posting it seems you're currently facing the same situation as we do.
Numbers of TYPO3 extensions (=modules) has grown to about 4k right now. We're handling issues in those modules with a lot less members in the Security Team than your team has recruited.

We are now in need of automated bulletin/advisory publishing process extended by issue handling between reporter and extension author only in the near future (of course overseen by the Security Team).

Educating people is also something that could be improved although there's already a lot of documentation for TYPO3 in regards to this.

Good luck! It's just a challenge on the way to the next level.

PS: We're hoping for a way better situation with FLOW3 with its Security Framework being basis of upcoming TYPO3 version 5.

Marcus Krause
Member TYPO3 Security Team