Movable Type: A History of Security
If you follow blogging news, you've undoubtedly heard a lot of concern recently about blogs on other platforms being hacked or blocked from search engines. Good news: Movable Type has a proven track record of having excellent security and an established reputation for fixing any known issues quickly. And that history of security is by design. We think there are some key things our community needs to know:
- We believe in making Movable Type secure out of our obligation to making the web better: Insecure web software can be a vector for spreading spam, viruses, and malware.
- Movable Type has the best security track record of any popular installable blogging software, according to the U.S. Department of Homeland Security's own reports.
- Movable Type security updates are prominently publicized on our Movable Type homepage, and through the application itself. Our team proactively contacts Enterprise and Community Solution customers if a security issue has been raised.
- Movable Type's security record is getting better, while other platforms are getting worse and seeing increasing numbers of reported vulnerabilities.
- When any issues have been found with Movable Type, they've typically been discovered through our own routine security audits, and fixed without ever having been exploited in the wild.
These facts show that Movable Type has a significantly different history than other platforms. But more importantly, they show that we're attuned to the concerns of the publishers and bloggers who rely on Movable Type to build their businesses and make a living.Â
We're not saying our track record is perfect. But take a minute and review our last security update in January. We listed our history of issues ("It has been 116 days since the last recommended update to MT4 and 273 days since the last recommended update to MT3.") and we mentioned whether applying the security fix would affect templates, plugins or performance. (No, no and no.) There are dozens of reasons to upgrade to MT4, from unique reporting and management features to powerful community capabilities. But above all, you shouldn't have to worry that sharing your ideas with the world or wanting to publish for a passionate community means putting your site, and your reputation, at risk.
The Bottom Line
While we're proud of our work, and especially proud of our community's focus on security, you don't have to take our word for it: Look at the data provided by a neutral third party. In this case, it's the U.S. Department of Homeland Security's own National Vulnerability Database. We searched the vulnerability database since 2005 for Movable Type and for WordPress, and included the partial reports for this year. In the chart, a lower bar is better. The results speak for themselves:
We think it's inarguable that there's a dramatic difference in the security of these platforms. And, as we've demonstrated for nearly seven years, we're working every day to maintain Movable Type's excellent record of security.
Between this and the reliability of a static publishing model[1], I think Six Apart has made a very profound case that Movable Type is *the* publishing platform for businesses, enterprises, and anyone else who values stability and security.
1. I'm referring specifically to Zeldman's Wordpress site that went down for half a day earlier this week.
Anil I completely agree with this post and I think that security and stability are major advantages that MT has, and has always had, over competitors.
Since the MT4.2 release I've been able to eliminate 2 plugins that I was using for extra secutiry: MT Akismet and Autoban. MT is managing the security better than ever and with less 3rd party helpers. Movable Type is by far the superior blogging platform.
There are a lot of reasons to upgrade to MT4, but one to stay in MT3: MT4 is the slowest CMS system i've ever used. It's a pity.
Anton, you're absolutely right to point out that MT4's performance isn't as fast as it should be. Here's the good news: MT 4.2, is up to 100 times faster in common tasks like searching, it's twice as fast out of the box with publishing, it has built-in caching options to get even more performance from your system, it's available now as a release candidate, and it'll be a free upgrade for all users of MT4.
We hear you loud and clear on this, and we're going to give you a version of MT that's not just super secure, but super fast, too.
I have recently decided to use MT instead of wordpress. This post explains almost 100% of the reason why.
This entry is highly misleading, perhaps due to a lack of understanding on your part about how the NVD works.
The "vendor" search for WordPress includes all third-party plugins. As there are thousands more plugins for WordPress than Movable Type this will obviously skew the numbers, making your comparison factually incorrect.
As an illustration I went through the CVEs for 2008 that listed "WordPress" as a vendor and found only 3 that applied to a core version of WP. A full 35 didn't even mention WordPress at all, they were just about plugins.
In light of this info, many of the conclusions you come to by citing this data are tenuous at best, and I would suggest axing your graph entirely until you've personally gone through the past 4 years of CVEs and verified them as actually applying to WordPress.
P.S. Typekey commenting is broken on this blog.
Thanks for the feedback, Matt. There are definitely different ways to represent the NVD data, but it’s clear that we have to evaluate platform security based on the security of the whole ecosystem. As an analogy, there have been many “Windows†security holes which were actually in applications or components that come with a computer or are distributed with a popular application but aren’t technically part of Windows. The net effect is the same: People’s systems weren’t secure.
The fundamental issue here is about what’s best for the web, not what percentage of responsibility is borne by Automattic or Six Apart or by third-party developers. It’s not good for the web if talented bloggers have to worry about getting pulled from search engines. It's not good for the web if all of us have to worry about sites and servers getting hacked. Whether those issues happened because of a core vulnerability or a commonly-distributed add-on for that platform, the net effect on the web is the same.
The distinction of "is this the fault of the platform or the plugins?" only matters insofar as placing blame. Our belief is that, in creating Movable Type, we have a responsibility to encourage the ecosystem to do the secure thing.
That's why we spend a lot of time building robust APIs in Movable Type for creating and managing objects, and then making sure they're forward-compatible so that developers use them instead of succumbing to the temptation to directly access the database. That's why we make the Movable Type templating system as robust as possible, so that adminstrators can make templates without allowing for scripting in PHP or other languages. If themes don't contain executable code, then they're not a vector for vulnerabilities of the kind that are apparently included in the data above.
I’m happy to caption the chart as “WordPress Ecosystem vs Movable Type Ecosystem†if you feel that’s a more appropriate description. But that doesn't necessarily affect the core goals here, or the conclusions that can be drawn.
An appropriate caption may be "WordPress + 2,423 plugins vs Movable Type + #? plugins".
Still though, there are a few fundamental problems here.
1. I have never seen someone attribute a problem in Windows to say, a vulnerability in Firefox, which runs on Windows, so I would strongly disagree with your ecosystem argument there. To consider 35 CVEs that don't even mention WordPress in your comparison is a misleading use of infographics.
2. The existence of CVEs has no correlation to actual problems in a given product. For example the vulnerability in MT last week still doesn't have a CVE for it.
In fact there was a MT security update in January as well, yet your graph still makes it look like there have been 0 security problems in MT this year.
3. I would also venture that this is a sign that no one inside of the MT team is proactively creating CVEs to track issues that were found internally, which you say catches most of the problems. To contrast every security issue I'm aware of in WP has a CVE to track it.
4. CVE creation and general public security review is much more common in Open Source ecosystems. Many of the more popular plugins for Movable Type are under proprietary licenses and unlikely to be reviewed by volunteer security professionals. Movable Type itself was under a restrictive license until recently, so for 3 of the years in the chart it was unlikely to have public review and therefore CVEs.
5. Vulnerabilities in MT plugins, like this one in Fast search last month, don't appear to have CVEs, which makes it harder for your users to know when there's a problem.
So in brief, WordPress security issues are better covered by CVEs and we also include an automatic plugin upgrade system, which I think is "better for the web" than obscurity and a false sense of security given by your claim to no MT security issues in 2008, when this comment mentions at least 3.
Typekey is still broken on this blog, the message: "The site you're trying to comment on has not signed up for this feature. Please inform the site owner."
This chart shows the Dep't of Homeland Security's data, and wasn't intended to show our own independently reported information. We'd all heartily welcome any independent security reporting of actual vulnerabilities and exploits as well, but this seemed noteworthy on its own.
In general, the reason we feel talking about the big picture with security is important to this conversation is because with Movable Type, users can often use templates to do what many WP users would do through plugins. Our native template tags go through security review both by our internal process and through the open source community, and it's common for MT admins to disallow scripting in their templates entirely, reducing the surface area for potential vulnerabilities to be introduced.
Since there's been a serious chance of WordPress sites getting hacked, it's obvious that that this is a situation where more plugins doesn't necessarily equal better. So, for a fair comparison, it makes sense to consider the whole ecosystem of what is commonly used to deploy a site.
In all, the best focus here is not to split hairs; Once we never have to hear about blogs getting hacked or people's sites being pulled from search engines, we'll all be the better for it. What we are doing is encouraging our developer community, both inside and outside our company, to follow best security practices. I hope you'll focus your obvious passion and energy on display here on encouraging your employees and community to do the same.
(And yep, I'd made a typo in setting up TypeKey. Never let it be said that I don't have a lot to learn about this stuff! :))
Matt,
I just went through the 2008 CVEs (now that 2008 is over) and found that 40 applied to WordPress plugins, 1 applied to PHP's random number generator, and 20 applied to WordPress core.
What I can't figure out is why you think this is actually a good thing. Not only are the number of WP CVEs non-trivial, the number of plugins with vulnerabilities in 2008 ought to give one pause about which plugins they install, if any at all.
For whatever it's worth, there are only 2 CVEs in 2008 in the NIST database and both belong to MT core.
MT: 2
WP: 20
Even giving away the CMS economy argument, WP was still ten times worse last year at least based on NIST data.