Drupal has a very good track record in terms of security, and has an organized process for investigating, verifying, and publishing possible security problems.
Drupal's security team is constantly working with the community to address security issues as they arise. More information about this process can be found in that section of the handbook.
Members of the security team sometimes perform analysis of core or contributed project code, especially if there is a weakness that can be found by easy scanning, but in general the team does not review core nor contributed code.
Anyone using Drupal should subscribe to the security mailing list (by editing your account profile) in order to automatically keep up to date with the latest security advisories of all types (see below).
Frequently asked questions:
Is open source software secure?
The short answer is that open source software is as secure or more secure (in general) than proprietary software (where visibility of the source code is tightly guarded and heavily restricted). A good summary of the relevant issues can be found in this article from IBM: The security implications of open source software. The increased security of using open source was cited as one reason the White House switched to Drupal.
How Drupal Addresses Common Security Vulnerabilities
Drupal's API and default configuration are designed to be secure when used in their default modes. Issues like Injection, Cross Site Scripting, Session Management, Cross Site Request Forgeries, and others all have standard solutions in the Drupal API. For a more detailed review of the topic please read the Drupal Security Report.
Why does Drupal have more (or fewer) security advisories than another project?
Unlike many proprietary projects owned by companies with commercial reputations and certifications at stake, community driven open source projects like Drupal have no incentive to hide security vulnerabilities - or even possible vulnerabilities. The best interest of the community is far more important than any commercial implications of being up-front with potential security issues.
The absolute number of security advisories (especially when including contributed projects) is a totally meaningless number and should never be used for comparison. Drupal has over 29,000 contributed projects that are scrutinized by their users for any potential problem, and a security advisory may be issued for a relatively minor issue. For more information read Security Risk Levels
A security advisory also indicates the discovery of a potential problem, and also that the problem is resolved already. It's extremely rare that such security holes are exploited in the wild prior to the security fix being announced in the security advisory. Thus, your most important protection is keeping Drupal up to date whenever a security advisory is issued for Drupal core or contributed code you are using.
On live sites, what vulnerabilities have been found or exploited?
Professional security audits of Drupal sites have generally found that the vast majority of security holes (90% or more) are present in the custom theme or modules written by that site's developers. That code did not get the same public scrutiny that all code on drupal.org receives.
In addition, problems at the server level (such as using insecure protocols like FTP) are more likely to be the means of a successful attack than a vulnerability in Drupal - especially Drupal core.
For information on how to manage security in Drupal, see the Securing Your Site section of the Drupal Administration Guide.