Drupal security process evolution
11 June 2010
The Register just published an article on recent changes to the Drupal security team's stance to release candidate (RC) status modules. The article notes that Drupal security has clarified their support of modules by specifically removing support for modules RC1 and higher. This is an important change because it means that many more Drupal modules are not supported.
Full disclosure: I was quoted for The Register article. I am not a member of the Drupal security team.
This announcement is a big deal, and it isn't. Drupal security coordinates security fixes of module code. This means that when Drupal security gets a report of a vulnerability in the module they coordinate the fix with the module maintainer. It is my understanding that the Drupal security team isn't necessarily proposing or writing fixes, although members of the team are active developers so it has been known to happen. In general though, it seems that module developers are responsible for fixes. This makes sense because module developers are much closer to their own code and can foresee problems with patches that outsiders might miss. This provides greater reliability for fixes.
The problem with this scenario is that dev, alpha, beta, and now RC designated modules are not supported by Drupal security. This means that security researchers have to report vulnerabilities directly to module maintainers, and are encouraged to do so through the public issue queues. This means that a vulnerability report is instantly public, in direct contravention of the closed manner in which Drupal security handles vulnerability reports in full releases. In a full release the details of a vulnerability are kept secret until a Drupal Security Announcement (SA) can be made.
This also means that vulnerabilities in full release that are addressed by SA prompt an alert in the Drupal administration section letting site owners know that they need to update their modules (in Drupal 6). If a vulnerability is found in an alpha, beta, RC, or dev module then site owners have no way of knowing about the vulnerability other than following the module's public issue queue (which virtually no one does).
Compounding the problem is the fact that many module issue or help queues will explicitly instruct users to "install the latest dev version" to solve bugs. This instruction is tantamount to asking users to install unstable, unsupported, and potentially vulnerable versions of modules in order to solve buggy behaviour (i.e. the solution to a display bug could result in the degradation of site security).
Obviously the Drupal security team can't be responsible for the security of all the code in the Drupal code base. Users should be aware of the risks of running anything other than supported releases however. Based on my personal experience 1 in 3 production modules has some sort of security vulnerability. I would assume this ratio to grow within alpha, beta, dev, and RC versions of modules. (As an aside I maintain a list of modules that myself or my colleagues have reviewed for security issues at http://www.sas.upenn.edu/computing/drupal-approved-modules).
I'm not sure Drupal security is doing all it could to encourage the community to examine module code for security flaws. There is a tremendous resource in open source security code review that could be leveraged to make Drupal even better. Creating a more transparent security process, having a site where researchers could follow their reports from initiation to resolution, coordinating security releases with researchers, and providing direct credit to reporters (not just a link to their Drupal.org profile) would be some concrete steps the Drupal security team could take to encourage greater participation. A rewards or feedback system (such as ranking or listing of bugs reported) could create a competitive environment in which researchers could strive to find as many bugs as possible. Assigning consistent handlers to security researchers could also help, so that researchers could establish relationships with individual members of the security team rather than dealing with the collective. Of course, the best thing I think the Drupal security team could do would be to solicit this sort of feedback, regardless of whether or not they think the researcher is an squirrelly issues (in my opinion) with how Drupal handles specific classes of vulnerabilities, but overall they do a great job. I have aggressively championed Drupal at my place of employment as a way to standardize web application code and to centralize security focus.
In conclusion, the Drupal security team is doing a great job. They have a lot to work with and they're definitely fighting an up hill battle. I really like the Drupal product, but believe it could be better. My only motivation for offering criticism of the project is to try to move it in a positive direction. Avoiding the use of Drupal due to security concerns would be a mistake. The Drupal security teams consistent effort and involvement only demonstrate their commitment to keeping the product vital and safe.