Add new comment

Drupal is a huge software project by any measure, with thousands of developers writing code for it and deploying websites and applications on it. It is one of the largest open source projects in the world, alongside Linux, Apache, and Mozilla. This infographic helps explain the important work of Drupal's Security Team.

Who needs protecting and why? How the world's largest open source CMS combines openness and security.

Drupal has gone from dorm room to board room in decade since its creation. It powers the web presences of hundreds of thousands of businesses, governments, universities, and others around the world. Developing code for Drupal now means writing code that could be used on any of those sites. Whether it comes from passionate hobbyist or full-time professional, Drupal's code must meet the very strict security requirements of banks, health-care providers, and governments, while keeping one step ahead of those trying to break into such systems.

Security and open source go hand-in-hand

Drupal's security process does need to be carried out quickly and discreetly to help fix problems before they become widely known or exploited. Nonetheless, security and open source go hand in hand – this may come as a surprise to those who assume that "security by obscurity" actually works. Hiding behind proprietary licensing or compiled code and hoping no one notices security flaws that have not been addressed is a recipe for disaster. Having your code open to anyone can result in greatly improved security – anyone can find and fix a problem. Working with a community of thousands of developers multiplies the benefits; anyone else's bug fix becomes your fixed bug, too. Security experts from the world's governments and largest companies regularly scrutinize Drupal's codebase for themselves and have judged it secure enough for their mission-critical applications.

Insecure code is usually flawed from the start. There are best practices that developers should follow to nip the vast majority of security problems in the bud. For this reason, the Drupal Security Team tirelessly spearheads ongoing efforts to educate and help the Drupal community prevent security issues from arising. They conduct presentations and training at Drupal community events and conferences, give webinars, write free online documentation, and maintain a public group to discuss Drupal security-related issues.

What is supported? Drupal core and stable release modules

The Drupal Security Team assists in handling the vast majority of security issues across the Drupal project and its contributed, plug-in modules. Modules with "development" releases are an exception; modules without a supported stable release ("1.0", "2.1", etc.) cannot receive the benefit of the Security Team's oversight. If you are considering using a module with only "development" or “beta” releases for a critical application, encourage the module's maintainer to create a stable, supported "x.0" release.

About the Drupal Security Team

The Drupal project formalized the existence of its Security Team in 2005 and rotates team leadership periodically. Code doesn't usually "suddenly become insecure", but some issues can be subtle and hard to spot. The rise of new technologies can make problems visible in new ways. A great deal of skill, knowledge and experience goes into making Drupal as secure as possible. The Drupal Security Team is now a mature, diverse group, currently comprising around 40 of the world's leading web-security experts (none of them robots, despite their skill and efficiency). They monitor and analyze problems that crop up "in the trenches" and work to improve the security of the Drupal project. Members of the team are dedicated volunteers from countries across 3 continents, including residents of Belgium, Canada, England, France, Germany, Hungary, Ireland, Japan, and the United States. The team draws members from consultancies, Drupal service providers, government contractors and Drupal's end-users, including non-profit, for-profit and education organizations.

The Security Release process

Vulnerability in code discovered. Bug hunters are everywhere! Anyone can identify and report a security issue to the team, including the team itself, module maintainers, the broader Drupal Community, security researchers interested in Drupal, and you. To report an issue, read and follow How to report a security issue on drupal.org.

Issue reported privately to Security Team. Security issues should be handled confidentially. The one exception is if a vulnerability requires advanced permissions or access to exploit – for example, the ability to administer filters or users. In these cases, the Security Team encourages module maintainers to fix these issues publicly because they don’t represent a threat on their own and they further harden the system when implemented. See the Drupal Security Advisory policy for further details.

Issue reviewed, potential impact on all supported Drupal releases evaluated. There are two major release series (6.x, 7.x, etc.) supported at any given time. You should always run and update to the most current version of the series you are using. See Choosing a Drupal version for further details.

If the threat is valid, Security Team mobilized for analysis. Maintainer notified.

Maintainer fixes issue. Security Team provides support. Maintainers, testers, and other interested parties are granted access to the issue on a private, secure issue tracker to collaborate on a solution.

Fixes reviewed and discussed. Steps 4 though 6 are repeated until the Security Team and module maintainer are satisfied the security issue has been addressed.

Code patches created and tested. The new code is tested to make sure it doesn't introduce other security issues or break the module in question.

New versions deployed on all sites. The "Available updates" report (at admin/reports/updates in Drupal 6.x and 7.x) on your Drupal site will tell you if your Drupal core and contributed module versions are up-to-date and give you download links and release notes for any new versions. Updates are not automatic and need to be carried out regularly to keep your code up-to-date and your site as secure as possible.

If your Drupal site is hacked or defaced

Help prevent this unfortunate occurrence from happening to others! Though unable to assist in individual cases, the Security Team would like to hear about your experience, in order to better protect the Drupal community as a whole. You can use the template at the page "My site was defaced. Now what?" to let them know what happened.

Plain text

Filtered HTML

Use [acphone_sales], [acphone_sales_text], [acphone_support],
[acphone_international], [acphone_devcloud], [acphone_extra1] and
[acphone_extra2] as placeholders for Acquia phone numbers. Add class
"acquia-phones-link" to wrapper element to make number a link.

To post pieces of code, surround them with <code>...</code> tags. For PHP code, you can use <?php ... ?>, which will also colour it based on syntax.