Aren’t those hosted and admined by WordPress staff (wordpress.com). There are obvioulsy things you can do to mitigate attacks that aren’t available to the regular user hosting a wordpress.org blog on their own isp.

The problem is not “My Dad can beat your Dad up,” because we are not children. Which is what, “Look at the past security problems” amount appear to be at the surface.

It is not easy to step up and say, “We were wrong in the past, here is how we are going to change.” It should not be a sign of weakness to tell people about security problems, and I don’t think it is a sign of guilt to not speak openly about security problems.

In the best case scenario, everyone would be on SVN checkout and upgrade whenever there was an issue. That does not appear to be the case. Whether the reason, by not upgrading any software, it opens the door for issues.

Your counting of CVEs in 2008 appears notably different from the one in the Codex that I did, albeit a few months ago:

Matt,

So it seems. I can’t speak to the “invalid” CVEs because I don’t have the requisite knowledge of WP to spot them, and I don’t know what you consider to be “legacy” since that term is not defined on the page you provided. I counted a total of 20 that were not plugins or third party and I didn’t happen to notice anything talking about WordPress.com, versus the distributable. I don’t know if it’s fair or not to use WordPress.com+WordPress distributable, but this post is throwing Movable Type and typepad.com in the same pot so that appears fair in this context.

I think we should discuss this, and set forth a common set of parameters so that this information can be reliable and agreeable amongst all. Hopefully I can get a discussion going on the MTOS list and maybe prod some better accountability out of 6A.

As an open-source project and more importantly community, WordPress makes sure every valid problem is listed with a CVE.

I’ve queried the MTOS list to see what the policy is on this and why it’s not more open, but I don’t have any direct control over that. They should be more forthcoming, but even if they aren’t, what does that have to do with the disparity between *known* MT vulnerabilities and *known* WP vulnerabilities?

But the proof is in results. If WordPress truly were swiss cheese than the blogs of CNN, Fox News, NY Times, Time Magazine, Wall Street Journal, and more would have been hacked a hundred times now, certainly around election time.

The individual security of those sites are not proof that WordPress is or is not secure. Matt Cutts urges people to limit access to the WP admin scripts by IP with .htaccess files — a wonderful idea — that could “secure” a site that still has active vulnerabilities. The security of site A is not proof of the safety of the software that site A runs.

What we can do is judge the security of that software by measuring its known vulnerabilities, and WordPress over the past two years has had quite a few.

Now that WordPress has built-in core upgrade functionality this should be much easier for everybody, even non-technical users.

It’s a good start.

http://codex.wordpress.org/CVEs

I think the point that 6A’s security problems don’t get as much attention is a fair one. At the time when they posted they had no vulns in the DHS database, they had already done at least one security release that year. So by definition there was a problem that wasn’t recorded in the CVE.

As an open-source project and more importantly community, WordPress makes sure every valid problem is listed with a CVE. Unfortunately because of how the database works lots of invalid things submitted by other people are in there as well.

But the proof is in results. If WordPress truly were swiss cheese than the blogs of CNN, Fox News, NY Times, Time Magazine, Wall Street Journal, and more would have been hacked a hundred times now, certainly around election time.

With any web application (or browser, or operating system) you need to stay up to date to be the most secure. Now that WordPress has built-in core upgrade functionality this should be much easier for everybody, even non-technical users.

A statement of assumption is not a fact nor an accusation.

Lorelle,

I’m not sure where you get “assumption” from.

The post by ck directly accuses 6A of covering up security vulnerabilities in order to “keep their security stats low (or non-existent)” with no evidence provided to backup such an irresponsible claim. And coming from a WordPress user (him, not you), it looks like nothing but petty sour grapes from a CMS fanboy.

Perhaps that is not the case, but it sure looks like it is.

Anil Dash admitted that few security issues ever see the public light, and most are discovered before they impact users.

And there’s a significant distinction and benefit between flaws found in-house that are never discovered in the wild, and those that are. The fact that few MT vulnerabilities are ever discovered and exploited in the wild is a good thing, it means 6A has security policies that are working while Automattic does not.

WordPress is definitely more transparent, and does fix security vulnerabilities before they ever see the public light.

If 6A and Automattic both fix vulnerabilities before they become known or are exploited in the wild , and yet WordPress still has significantly more vulnerabilities discovered and then exploited in the wild, then WP has a serious problem and it seems pretty reasonable for 6A to be able to claim to be one of the most secure CMS platforms out there.

Moreover, why do people use it as a sign if dishonesty or deception when 6A does it, but a positive when Automattic does it? It smells like a double standard.

Even with the high concern and fast response times to these issues, WordPress is more often accused of being “swiss cheese” by many, as you can see in the comments here, when that accusation is also not the truth.

How is it not?

After leaving a comment here, I returned to Dash’s post on MT security and read through some of the comments and took up (partially) a challenge that Matt Mullenweg had left. I went through all the reports in the NIST database for 2008 for Movable Type and WordPress and did a separate count the core, plugins, and third party libraries and applications.

Movable Type had 2 reports for the entire year, both affecting the core. WordPress had 20 reports for the core, 40 for plugins, and 1 for a third party lib/app (PHP’s random number generator).

The total for 2007 was the same as 2008 overall, a little more than 60 vulnerabilities according to NIST. If that breakdown holds, that means that WordPress didn’t get any more secure in 2008 than it was in 2007. Meanwhile, like it or not, there havn’t been more than 5-6 reports for Movable Type in any given year, and some years there are as few as 2 (such as 2008).

The DHS graph and other security monitoring systems for security vulnerabilities are often misleading, I’ve found out. WordPress admits theirs right up front, and often these WordPress specific issues have to do with MySQL, PHP, and Plugins rather than the core of WordPress, leading many to assume WordPress is less secure.

Saying that the graph is misleading without bothering to verify it for yourself is equally as bad as relying on the graph as accurate without verifying *that* either.

Well, I did verify it:

WordPress 2008:
Plugins: 40 reports.
Core: 20 reports.
Third party: 1 report.

Movable Type 2008:
Plugins: 0 reports.
Core: 2 reports.
Third party: 0 reports.

The total of 61 reports for WordPress is misleading, the total of 2 for Movable Type is not, but WP is still looking like swiss cheese to me.

And to address a comment of yours from above but addressed to somebody else:

WordPress is still in the early years of its development and last year taught the WordPress Community a lot about security issues.

WordPress is over five years old. If it took four years just to start caring about security and there are still excuses being made half a decade after being created, I see no reason to believe that WP will ever be safe to use.

Personally I hope that isn’t the case. I’d be thrilled if WP actually did start caring about security given the installation base, but we need to see results follow promises *first*. Until the results come, the WP security track record is awful and getting worse by the day.

WP2.7 is a significant change. Our in-house testing revealed that the new UI is less usable for our company, while the new comments features are unneeded (and unwanted) by us. The automatic upgrades present some significant risks to us so our only option is to remain on 2.6.5 and keep as much up-to-date with security news as possible. Or move to a different platform.

WP does not clearly identify code changes that are made for security. This makes it hard for anyone to make manual changes to harden their sites.

The DHS graph and other security monitoring systems for security vulnerabilities are often misleading, I’ve found out. WordPress admits theirs right up front, and often these WordPress specific issues have to do with MySQL, PHP, and Plugins rather than the core of WordPress, leading many to assume WordPress is less secure. I don’t work for WordPress nor Automattic, nor Movable Type or others directly. I am an advocate for WordPress, which makes me biased, of course, but I’ve learned that such reports don’t tell the whole picture, since there is no single reporting agency nor requirement for reporting. The WordPress Community is very response and reports widely, whereas other platforms keep their information closer to the chest.

They are #1 on your recommendation page.

I’ve suggested this before: put Bluehost/Fantastico on notice. Get with it, or get dropped from your recommendation list.

It might also help if WordPress didn’t resemble Swiss cheese.

Repeating such accusations without proof isn’t a terribly responsible thing to do, imho.

2005
WordPress: 11 vulnerabilities
MovableType: 6

2006
WordPress: 18
MovableType: 1

2007
WordPress: 49
MovableType: 3

2008 YTD (June)
WordPress: 42
MovableType: 0

I’m not sure what the search criteria was for that graph, so I just ran two searches of my own for basically all types of vulnerabilities and all severity.

WordPress
2004: 2
2005: 13
2006: 21
2007: 63
2008: 61
2009: 0

Movable Type
2003: 1
2004: 0
2005: 6
2006: 1
2007: 3
2008: 2
2009: 3

Make of it what you will.