Last updated November 22, 2016. Created on May 28, 2009.
Edited by David_Rothstein, Pere Orga, dokumori, mlhess. Log in to edit this page.

What is a Security Advisory?

A security advisory is a public announcement managed by the Drupal Security Team which informs site owners about a reported security problem in Drupal core or a contributed project and the steps site owners should take to address it. (Usually this involves updating to a new release of the code that fixes the security problem.) The problem is kept secret until the advisory is ready to be released, at which point it is publicized widely so that site owners can address it quickly.

For examples, look through past security advisories for Drupal core and contributed projects.

Which Releases Get Security Advisories?

Security advisories are only made for issues affecting stable releases (Y.x-Z.0 or higher) in the supported major version branches (at the time of writing Drupal 7.x and Drupal 8.x). That means no security advisories for development releases (-dev), ALPHAs, BETAs or RCs.

Support means both as supported by Drupal core and by the project maintainer via their project page.

The requirement for a full release means that the Security Team will not create an advisory for "sandbox" projects nor projects hosted via external repositories such as some distributions.

We do not take the usage of a project into account to keep this policy clear for our users.

What About Vulnerabilities Which Require Advanced Permissions?

Another case where no security advisory is required is when an exploit requires one of the following permissions:

  • Access site reports (a.k.a. "View site reports")
  • Administer fields (added in Drupal 7.50)
  • Administer filters
  • Administer users
  • Administer permissions
  • Administer content types
  • Administer site configuration
  • Administer views
  • Translate interface
  • Any other permission that is defined with "restrict access" set to TRUE -- see the hook_permission documentation for more information

Any user with one of the above permissions can already take over the site or bypass various access restrictions on the site, so there is no meaningful added risk if a vulnerability is only accessible to a user with one of these permissions.

What about security issues that can't be exploited?

There are often instances where it is unlikely that an issue can be exploited on actual sites. In these cases the team considers several elements to determine whether the issue should be handled in the module's public queue or the private queue:

  • If there is a way to exploit the issue by installing a contributed module then it should probably be handled in private.
  • If the steps to exploit the issue are extremely complex it can more likely be handled in public.
  • If the solution is likely to be controversial or difficult to get right then it is more likely it should be handled in public.
  • If there is no known way to exploit the issue and it's difficult to imagine a way to exploit it without some other attack already in place (e.g. SQL injection) then the issue can probably be handled in public.
  • If the issue is related to insecure cryptographic storage of site keys (e.g. they are stored in plain text in the database) that is disclosed or reasonably expected of the module then the issue can be handled in public. If a module stores sensitive user information in a non-encrypted format that should be handled as a private issue.

For example, an issue that requires a username that contains XSS cannot be exploited with core alone because core has validation on usernames. However, it is likely that a module importing users or making usernames from an external source (like distributed authentication) will allow non-standard usernames that might contain malicious characters. So, in the past there have been issues handled privately and with an Advisory to fix XSS in user names. On the other hand, an XSS issue related to other names (e.g. languages) that are unlikely to be entered/imported from an untrusted source can be handled in public.

Always report the issue to the team and let them make the decision on whether to handle in public or private.

How does the "Security update" taxonomy term relate to Security Advisories?

In addition to the list of security advisories there is also a taxonomy term for security updates. The security update term is part of the set of tools used to communicate security issues and plays a role in how the Update module (part of Drupal core in 6.x and above) displays update messages to site administrators. Module maintainers may use the "security update" tag even if no security advisory is created as a way to indicate a new release (perhaps from Alpha to Beta) where security issues were fixed even if it doesn't meet the criteria for sending a security advisory. Note that releases tagged "Security update" are not automatically published so you need to contact the security team to get it published.

The reason for this policy is not to try to hide vulnerabilities, but simply to provide a mechanism for alerting people to problems with developer-level releases that doesn't create the noise nor require the overhead of a normal security advisory.

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.

Comments

podarok’s picture

The worst initiative I've seen on Drupal.org
In short term this is awesome, btw, but in long term you'll get an army of people which can't write secure code. Just because there are old guys that take care about that... No need to care, though...

---------------
Andrii Podanenko
web(uk, en)
personal blog(uk)

David_Rothstein’s picture

I don't understand what this comment has to do with this page.

Jaypan’s picture

Yeah that post makes no sense.

Charles Belov’s picture

Currently, if a stable release of one module is dependent on a dev/alpha/beta/rc release of another module, the stable module is considered supported by the security team. For instance, as of January 26, 2017, Workbench Moderation 7.x-3.0 is dependent on Drafty, which is in version 7.x-1.0-beta3; Workbench Moderation is nevertheless flagged as having Drupal Security Team support.

Is this appropriate? Or would the best practice be a requirement that the chain of dependencies for a stable contrib module also be supported by the team in order for the stable contrib module to be supported?

Charles Belov
SFMTA Webmaster
http://www.sfmta.com/

mmerrill219’s picture

What hoops do we need to jump through to get the cute green shield next to our module project releases?

Jaypan’s picture

Well, you have to choose 'opt in' on the module edit page. After that though, I don't know. I did that two weeks ago on a project, and I haven't received any reply, nor is my module shielded.

It would be nice if this was a little clearer.

mmerrill219’s picture

Thanks for the reply.
Even though I have can make projects now... I can't opt in.
So I going to ask them for that permission.
Afterwards I'll write a detailed post or fix those pages and/or links.

Jaypan’s picture

I applaud this issue, but the lack of documentation about how one goes about getting a module covered by the security policy is frustrating. As far as I can tell, there doesn't appear to be any documentation, other than a couple of vague comments on this page.

I have released a module with a full version, and that version is set as the recommended version, and I chose to opt-in. Yet my module is not covered by the security policy. I did this two weeks ago, and have not received any contact from anyone, nor any indication whatsoever whether I'm waiting for something, or if I've done something wrong, and with no documentation to explain the process, it seems like a big black hole.

What is the point of having a security advisory policy, if there is no clear way on how to achieve getting a module covered by it?

Wim Leers’s picture

I suspect there's a bug on d.o.

Compare https://www.drupal.org/project/cdn with https://www.drupal.org/project/http2_server_push.

Both have opted in to the security advisory coverage. Both have their a branch set as recommended, and they each have a .0 release in the recommended branch.

But the CDN module has <tr class="recommended-yes security-covered"> and the other one has <tr class="recommended-yes security-">>. In other words: it looks like the "security"-related class is not being set correctly for newer projects.