When it comes to security, there are major differences between a proprietary content management system and an open source CMS. Let’s discuss.
Are you watching the news and feeling less secure these days?
If you follow the news you may have noticed stories about data security—the lack thereof—seem to be reported at an increasing and alarming rate. These attacks initiate from multiple sources and affect various platforms. They range from concerning to infuriating to just creepy.
If you are in the market for a content management platform, you are reading these stories with particular scrutiny as you consider your choices. As your head spins with the dizzying number of options, you will eventually be drawn into a debate on the merits of open source CMS platforms. Open source options offer flexibility, freedom and cost-effectiveness (for the software portion of your implementation at least), but the factor of security weighs heavily in this equation.
Open source development emerged in the late 1990s, introducing collaboration and cooperation into the software creation process. It was a major departure from traditional development where programmers were paid from software companies' profits and source code was guarded as intellectual property. Creating a community of developers and availing the code to anyone with a dial-up broadband connection seemed reckless to some, but it was argued the sheer transparency ensured accountability, revealed bugs and ensured good behavior. Although the software was effectively free, the products developed with it can be marketed and sold. Today, many products are produced in this way with maintenance and services creating revenue streams for many organizations.
It is a fair question, and you will get very different responses depending on who you ask. The debate focuses around two major distinctions between open source and proprietary systems. The first we’ve touched upon—access to the source code. The second difference is the programming languages used to develop open source projects. They align among several options, so when we consider security of open source systems, we need to consider inherent security of the programming languages themselves.
Open source content management systems like Drupal, WordPress, Joomla and others are generally created by a massive community of developers. No one specifically owns the responsibility to secure the system, but since each developer has a vested interest, the reasoning is that vulnerabilities will be fixed as they are discovered. The developers are motivated by commitment to the project and the chance to build a reputation in the community.
This application of self-interest and tribe mentality is considered more energizing than monetary compensation. Furthermore, these internal motivators are not prone to scarcity of time, budgetary restraints, and personnel policies.
Proprietary content management systems like Adobe, Sitecore, Optimizely, Progress Sitefinity and many others, only allow their own developers to see and change the code. These companies protect their investment by hiring talented internal teams to develop and test their product. As a practical matter, these teams are smaller than the open source developer communities, but as employees, supported by the formal structure and security of a business environment, they have latitude to focus full-time on the project and benefit from the synergy of a team structure.
In practice, neither model exists in the purest form. Open source CMS developers are often professional programmers hired by companies to work on open source projects. They contribute to the work of the community while also collecting a paycheck. Some enlightened companies even allow developers time to work on side projects, to promote professional development and perhaps produce marketable results for the company. Predictably, some of these projects are open source.
And although open source CMS developers are clearly driven by passion, it is only fair to point out that salaried developers working for proprietary CMS software companies derive satisfaction from their work as well. The best coders have wide latitude for whom they will work and will seek out the best projects.
Motivating factors are always a mixture of many elements. Indeed, open source communities also serve as professional networks with members joining in hopes of increasing their earning potential.
Open source developers use a number of programming languages including PHP, SQL, MySQL, Java, JavaScript, and Python, while developers of proprietary platforms are more likely to use ASP.NET with C# or Java.
Most stories of open source vulnerabilities tend to imply that the languages used by open source developers are less secure, but it is not that simple. Website hacks generally occur due to vulnerabilities in plugins and themes, not the CMS software itself.
More important than the language chosen, is the care and professionalism of your development team. The truth is that the good programming practices will produce a secure project and poor programming processes will have the opposite effect.
That said, some environments are better suited to enforcing good practices. Microsoft’s .NET Framework and .NET Core, for instance, contain features designed to aid in secure development. Teams that plan effectively and rely on these features are much more likely to create a secure product. That is one reason companies like Progress are committed to .NET development.
Interestingly, in 2014 Microsoft opened the source code of the .NET Framework and their developer platform continues to be open source with the release of .NET Core. Microsoft did this for good business reasons, promoting its ecosystem and encouraging cross-platform development. It seems ironic, but in fact, reinforces the notion that in the proper context open source has great value. But the context, as always, is very important.
In its proper place, open source development fosters creativity and collaboration, but it is precisely for this reason the content management systems built with open source development become vulnerable.
Security patches and software updates must be applied with diligence and regularity to stay ahead of any creative hacker who would take advantage of a vulnerability. This is true whether the product is open source or proprietary.
With propriety systems, when a vulnerably is discovered, the change is made in the code and the update is released with an explanation of what was fixed. The vulnerability is somewhat hidden by the secrecy of the code. With open source systems, however, the changed code is released with the fix or workaround. The source of the vulnerability is exposed, and nefarious attacks can be made to anyone who has yet to apply the patch.
AAs stated before, it is rarely the CMS itself that is vulnerable to attack but the plugins and dependencies that expose a website to a breach. Integrations in an enterprise-level system are much more likely to require complex connectivity. Implementations with multiple integrations and a proliferation of sensitive data may not be good candidates for automated patching. For this reason, proprietary CMS systems offer some cover by keeping the reason for the patch hidden from public view.
For that reason alone, in any enterprise-level CMS implementation, the safest course of action is to stick with a propriety system while employing a diligent, patch management plan.
J.D. Little is a Senior CMS Market Strategist, a creative communicator, an educator and an advocate for change. Beginning his career in traditional media technology, he has been helping business leaders navigate the waves of disruptive innovation for more than 25 years.
Let our experts teach you how to use Sitefinity's best-in-class features to deliver compelling digital experiences.
Learn MoreSubscribe to get all the news, info and tutorials you need to build better business apps and sites