Security team

Goals of the security team

• Deal with reported security issues.
• Constantly review the code for potential security weaknesses.
• Provide assistance for contributed modules' maintainers in dealing with security issues.
• Provide documentation on how to write secure code.

How to report a security issue

If you discover or learn about a potential error, weakness or threat that could compromise the security of Drupal, please mail your concern to the Drupal security team: security@drupal.org. Please provide as many details as you can about the environment, Drupal version, modules used, their versions and so on. For more information, see how to report a security issue.

If you are required to encrypt your report, use the OpenPGP key: 0xA1FDFAC2.

How we deal with reported security issues

• Review the issue and evaluate the potential impact on all supported releases of Drupal.
• If it is indeed a valid problem, the security team is mobilized to eliminate it.
• New versions are created and tested.
• New packages are created and uploaded to Drupal.org.
• We will utilize all available communication channels to make it known that a security issue has been found and fixed, and what steps must be taken by Drupal administrators to protect themselves.

Recommended Core Security Improvements

A report was written about Drupal security in 2007, by Google Highly Open Project, high school student Jesse Crawford.

Security announcement and release process

The security team believes that providing security requires more than simply posting a patch to Drupal.org. The security team recognizes that hundreds of thousands and maybe even millions of people rely on the Drupal security team to notify them of known vulnerabilities. In the third quarter of 2007, the security team adopted a coordinated security release policy to help raise awareness of security issues and to make managing security patches manageable. The security team now coordinates security announcements in release cycles and evaluates whether security issues are ready for release several days in advance. Most importantly, the security team is coordinating with the Drupal maintainers, particularly the Drupal 6 maintainers, to ensure security releases are coordinated with major Drupal releases, such as betas and release candidates. This improves the visibility of security releases and allows for effective coordination of the maintainers and security team resources. However, this has lead to several complaints that individual patches are not being released quickly enough.

We believe that we must consider the needs of the site maintainers and their ability to have have regularly spaced security announcements. We must also consider the effective use of the security teams limited resources to remain vigilant and available over the the long term of the Drupal project. If you have a concern with the response time of your security release we welcome you to publicly discuss this policy, but would ask that you leave the details of any non-disclosed release private until the security team creates an official release.

Disclosure policy

Our policy is one of full disclosure; we will never withhold information about a security problem and hope that it won't be discovered by others. However, public announcements will only be made when the threat has been addressed and a secure version of Drupal is available. We ask that when reporting a security issue, you observe these same guidelines, and beyond communicating with the security team, do not share your knowledge of security issues with the public at large.

Which versions are supported?

• Not all historical versions of Drupal are actively supported only the current and one back (at this moment these are 6 and 5). Versions of Drupal that are not actively supported will not get security releases. It is therefore not recommended to run unsupported versions of Drupal. Please upgrade so that you will benefit from security releases.
• The development branch of Drupal is not intended for production use and while security problems are fixed, security announcements are not issued. If you are using the development branch for testing or evaluation, we assume that you will update your code regularly.
• The security team oversees the security of the code found in the core Drupal distribution. The security of contributed modules and code lies with the individual maintainers. See the process below.

Issues with contributed modules

As soon as we learn about a security issue with a contributed module, we forward that to the maintainer of said module with a deadline. As soon as the maintainer fixed the problem, the security team will issue the relevant advisory with instructions on how to upgrade. However, if the maintainer does not fix the problem within the deadline, an advisory will be issued nonetheless, but we will advise to disable the module and we will disable the project as well.

How to get involved?

The most important help you can provide is reviewing proposed patches with a security mindset. You can also help by reporting issues and working with the team on a fix.

Security team members

• Angela Byron
• Khalid Baheyeldin
• Dries Buytaert
• Robert Castelo
• Stéphane Corlosquet
• Heine Deelstra (team leader)
• Robert Douglass
• Neil Drumm
• Dmitri Gaskin
• Gábor Hojtsy
• Morbus Iff
• Bart Jansens
• Barry Jaspan
• Chris Johnson
• Gerhard Killesreiter
• Andy Kirkham
• Greg Knaddison
• Erdem Köse
• Kieran Lal (coordinator)
• Adam LIght
• Karoly Negyesi
• Darrel O'Pry
• Chad Phillips
• James Walker
• Moshe Weitzman
• Matt Westgate
• Peter Wolanin
• Derek Wright