Like all popular software, WordPress is in a bit of a bind. It’s popular because it’s widely recognized as the best content management system by a large number of sites and users, but that popularity comes at a price. Online criminals know that if they can find an exploit in WordPress, they can access millions of sites, so they devote significant resources to finding problems in WordPress. And its popularity also means that the media pays particular attention to WordPress vulnerabilities when they are found.
If you’re a follower of the WordPress blogosphere, you’ll know that articles tend to fall into one of three groups: discussion of WordPress releases and plugins, howto articles, and news of security vulnerabilities. It’s not that WordPress is any more insecure than any other CMS — it’s a lot more secure than most — but journalists are always look for a good story and “tens of millions of website are vulnerable to hackers” makes for more clicks than “WordPress is awesome.”
When businesses are choosing a content management system, you can put money on most of the decision makers having heard about WordPress security problems. It doesn’t really matter that WordPress is no more prone to problems than any other piece of complex software — it’s WordPress that they hear about. And that makes business decision makers wary of choosing WordPress, putting WordPress professionals in a difficult position.
In order to tackle the problem, WordPress has released a security white paper that goes into some depth — while remaining comprehensible to non-techies — about what it is that the WordPress developers do to keep the application secure.
If you’re interested in WordPress, you should definitely take a look yourself, but the highlights are a thorough discussion of the WordPress release cycle with a focus on security; the makeup of the WordPress security team, of which half the members are Automattic employees; and some information about what WordPress does to keep the CMS safe from the ten most serious security risks.
Of particular interest is the section that briefly discusses plugin vulnerabilities. The authors make it quite clear that inclusion in the plugin repository is not a guarantee that the plugin is free from security vulnerabilities, but that the development team make a concerted effort to minimize risks: if the Security Team discovers a vulnerable plugin, they will work with the author to correct the problem, pull the plugin from the repository if the author is non-responsive, or, in some cases, the security team will implement fixes themselves.
The security white paper — which can be downloaded as a PDF — is likely to be useful to WordPress professionals, plugin and theme developers, and hosting providers who create software for WordPress or provide WordPress services to clients.