CMS Security – Closed vs. Open Source

I was recently asked by a client of ours to do a comparison of a few content management systems for a project that they are currently working through. One of their key concerns was security and I collated my thoughts on the matter… so I thought I’d share them with the wider world.

I’ve used ‘in theory’ where I’m making assumptions.

Thoughts on security in general

Saying open source is more secure or less secure than closed source is not something anyone can say with any real objective evidence. There are essentially two completely different methods of security at play here, best described as security through obscurity (closed source) and security through transparency (open source).

Security through transparency

If we look at the latter first, open source platforms (WordPress, Drupal, Joomla for example) are developed by 10,000s of developers across the world. As the source code is open and visible, it means that in theory the huge developer communities that work on these open source platforms can test new code to a far greater extent than those written in closed source environments.

It also means in theory, that more vulnerabilities will be found and fixed, as there are more developers testing the code. It also means that vulnerabilities, when discovered, can be fixed more quickly, as there is much more development resource available to make the fix. It does also mean though that vulnerabilities are highlighted to the world at large, and therefore, hackers.

All of this however, works to ensure a secure code base, especially in mature open source CMS platforms like Drupal which launched in 2001 and has now had over 10 years of open source development. Drupal are very open about the security vulnerabilities they discover and patch. You can see them all here:

https://drupal.org/security

On the core Drupal platform, there have been 10 security alerts over the last 3 years, and only 2 this year so far.

Security through obscurity

On the flip side, from a closed source perspective, this means that the code base is owned, tested and updated by a team of developers and the world has no visibility of the server side code at all.  These teams are specialist developers and in theory know their own software well, meaning they in theory know some of the potential vulnerabilities and put in practices to minimise security risks.

Partner development agencies are allowed to integrate sites, and in some cases, extend the original functionality of the platforms, but again, this code is kept closed (for the most part).

This in theory, makes it less straight forward for hackers to find vulnerabilities in the first place. If you can’t see the code, you can’t get at the vulnerabilities… Unfortunately, it’s not that straight forward.  Hackers are very clever, and if they are so inclined, not having the source code isn’t going to stop them hacking something.

In my research, I’ve stumbled across various tools they have at their disposal (things like IDA pro for example) which will actually give them the ability to reverse engineer the code instead. Tools like this work across open and closed source platforms.

So, just because the code is closed source, it doesn’t make the software itself more secure. Let’s not forget, companies like Microsoft and Adobe develop on a closed source basis, and vulnerabilities here are exploited regularly too.

A quick search reveals details of vulnerabilities in the closed source CMS’s too, they just aren’t published on the closed source platforms public facing websites.

Security through good practice

Really what I’m getting to is that software is not more secure or less secure because it is open or closed source. Secure software design, source code auditing, quality developers and design process all play into the security of a piece of software, and none of these are directly related to a project being open or closed source.

From a CMS perspective, no matter what solution you choose it won’t be 100% secure. The most important thing is that the software is maintained well and kept up to date. Leaving the software out of date, means leaving vulnerabilities open, so combating that is the best way to stay secure.  For the most part, your closed source CMS license fees will cover updates. If you choose an open source platform you’ll need someone to update the CMS (a techy, an agency, etc).

More to security than the CMS

It’s important to remember though that the CMS is just one piece to the security puzzle. The server environment is another factor.

In 2011, Linux servers were running around 80% of the websites in the world (including Google, Yahoo, and Facebook).

Again, people argue whether Windows servers (closed source) are more secure than Linux servers (Open source) which you can see more about here: http://www.cyberciti.biz/tips/is-linux-really-more-secure-than-windows.html

This article makes a similar point, as long as the server is well managed, and kept up to date, it’s secure as it can be, but a server will never be completely secure.

So what’s the answer?

I’m certain the open vs. closed source argument won’t be solved anytime soon (and I doubt my non-committal post will help with the resolution). They have different models of ensuring security but neither is conclusively better than the other. As long as you choose a CMS that is tested and updated on a regular basis, then you’ll be as safe as you can be.

From a security perspective, good security practices will have a much greater effect on security than whether you’re on an open source of closed source platform.

There are so many different CMS choices, you’ll never be able to compare them all. The important thing to remember is that your choice should be led by much more than just security. Functionality, usability, and of course budget all need to play a role too.