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 6.x and Drupal 7.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:
- Administer filters
- Administer users
- Administer permissions
- Administer content types
- Administer site configuration
- Administer views
Any user with one of the above permissions can already take over the site, so there is no meaningful added risk if a vulnerability is only accessible to a user with one of these permissions.
In addition, Drupal 7 gives modules the ability to specify whether permissions should be restricted to trusted users, using the "restrict access" return value from hook_permission. Since this changed between Drupal 6 and 7, a Drupal 7 issue in which "restrict_access" is set to TRUE -- for permissions also present in Drupal 6 -- will justify a Drupal 6 advisory as well.
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 an SA. 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 SA.