It's Nearly 2016, Your Site is Running on Drupal 6, Now What? Part 2: the Risks

This is part 2 of a series investigating what to do with your Drupal 6 site as EOL approaches.

• Part 1 - overview
• Part 2 - the risks
• Part 3 - the options
• Part 4 - Drupal 7 or 8?

It is helpful to think of the risks of running publicly-accessible software, like a Drupal website, after end-of-life (EOL) from two distinct perspectives.

1. Bad things that can happen to your organization due to known security vulnerabilities that may be exploited by the public.
   • These are the kinds of risks we typically think of when running outdated software. Hackers of the worst kind… the one’s that are after you!
2. Good things that are less likely to happen (or even be possible) to your site when you run old software.
   • Though easy, it’s important not to underestimate this opportunity cost, as it is more subtle, often less pressing, harder to quantify, but ultimately often more costly than the former.

Bad things that can happen

In the worst of scenarios, it is possible to experience

• Complete site compromise and escalated server access due to a vulnerability exposed by website code.

Yes, it is possible that with outdated and insecure code, especially when the exploit is publicly disseminated, your site is exposed to complete control by a nefarious (or simply bored) hacker. The best and decreasingly recent example in the Drupal world is a security vulnerability (for sites running Drupal 7.31 and earlier and Drupal 8.0.0-beta2 and earlier) affectionately referred to as “Drupalgeddon” (yes, the world is coming to an end if your website is compromised). You can read until you’re blue in the face about this significant exploit, but suffice it to summarize that a visitor without an account on your site could completely control it with a sophisticated exploit of this vulnerability. Given the hacker will have access to nearly everything on the server, he may choose his means to best exploit your site. He may

• Add spam marketing links throughout the site.
• Defame the site if you’re a high-trafficked, reputable organization.
• Use your server to send spam emails.
• Use any sensitive data especially financial he’s able to access by his own mean. It’s been done.

Unfortunately, we’ve had a client return to us to rehab a site that has undergone this vulnerability, suffering at least 2 of these unpleasantries.

Having said that, given that Drupal 6 was released in February 2008, it is less likely (though not impossible) that such a large vulnerability still exists in the core code of the project. Higher risk vectors are contributed modules (i.e. plugins/extensions), especially those that haven’t been maintained, and certainly custom modules, which we’ve seen at Savas Labs vary widely in adhering to best security practices depending on the agency and/or developer who wrote it.

Therefore assessing risk factors for a Drupal 6 site as a whole is nuanced, and requires a comprehensive site audit.

More subtle risks

Outdated software tends to present unpredictable obstacles based on the fact that most of the world is no longer using the software. While your Drupal 6 site may be fairly static from a code standpoint, the world around it continues to adapt, update, and improve. This is the world of PHP, MySQL (the database software used by most Drupal sites, others are Post), and Apache (the web server used for most Drupal sites).

Hosting providers have an interest in keeping their servers and systems up to date for the same reasons we’re discussing here: security, performance, and functionality.

After we had finished a project with no maintenance contract with a former client they authorized routine server maintenance and promptly rendered their site to the fabled White Screen of Death due to fatal errors caused by a PHP version update incompatibility with their code. Though we were happy to step in during the emergency, we appreciated how difficult it was to see coming for the client.

Much akin to the long-awaited Drupal 8 release, PHP 7 just came out and boasts, like Drupal, functionality and performance improvements. According to a d.o post Drupal 8 is 100% PHP 7 compatible.

Drupal 6 recommends a decidedly small range of PHP versions – between 5.25 and 5.3. This is potentially problematic for Drupal 6 sites since PHP 5.3 is itself over 6.5 years old. Hosting providers don’t like that, and as time goes on there will be upward pressure on the version number providers are willing to support.

Good things that can’t (are unlikely to) happen?

Given exploitative risks vary by installation and implementation of your Drupal 6 site, let’s look more definitively at what you won’t have access to with outdated software.

Your organization cannot reap the benefits of the modern web.

One example here is the concept of responsive web design. Pulling off a responsive design for Drupal 6 is very difficult. The concept was quite fresh when Drupal 7 was officially released (2011). Even though most Drupal 7 development took place before RWD, the community was able to evolve with it and provide solid offerings for responsive themes and frameworks in the Drupal 7 repository. Drupal 8 was built mobile-first and therefore is responsive out of the box. Another example would be the much improved, native content editing experience in Drupal 8. Content editing improved from Drupal 6 to 7 and made a leap from 7 to 8 with inline-editing and wysiwyg in core.

You expose yourself to a shrinking market of developers that are able to serve you.

Each of the last two major releases of Drupal entail significant architectural shifts from the former. Requisite skills in Drupal 6 for example look fairly different than those for Drupal 7. Even greater disparities exist when comparing the object-oriented Drupal 8 to the mostly procedural Drupal 6. We as developers like to build with what’s new, and most of the market does as well, so the longer you hold out past EOL the smaller the pool of accessible talent which could also drive up the cost to contract due to scarcity. Given the limited pool, you may have to settle for an inexperienced developer, which can result in poor code quality and the associated costs that come with it. Not least of which is the risk of increased technical debt that you may have to deal with down the line and has been estimated to cost $3-$5 per line of code written.

We have a client whose undocumented and non-standard code written by several former developers still provides the occasional production surprise and we’ve been working with it for 1.5 years. This has caused our client hundreds of hours of lost productivity spent debugging, commenting and improving legacy code rather than creating new functionality and features for marketing or other business needs.

The opportunity costs of using old software means more limited feature-set, and likely poorer performance.

A diminishing feature-set might mean you cannot easily or affordably access a hero image homepage carousel (all the rage these days) for example. Or it might mean you’re unable to provide an editorial workflow for content publication for different roles in your organization. Whatever the need may be, ultimately using EOL software means you will have access to what was popular while that software was in active development, which is likely many years prior. Upgrading to current and actively developed software means access to the web’s current needs.

And what about site speed; how important is that? According to many different sources, VERY important.

Suffice it (once again) to say that site load speed is critical and says something about your organization’s credibility. One example of an advanced web development feature available in Drupal 8 is the impressive bigpipe project which leverages the power of a performance tool designed at Facebook to the betterment of the Drupal community! It’s a game-changer for caching and page responsiveness.

Your site looks/feels outdated.

Let’s face(lift) it: We can usually tell when a website is … aging. It’s somewhat unavoidable with a Drupal 6 site as it was likely designed many years ago using practices that were the norm then. Your website is your first and most important means to convey trust and credibility. Much of the research on users’ assessment of credibility from your website references the (ironically poorly designed) work of BJ Fogg of Stanford. Not surprisingly web design tops the list as most important credibility marker, and your Drupal 6 design and feature set is likely not going to cut it any longer.

Given we have described the risk of operating a Drupal 6 site after EOL, we’ll explore your options as dictated by your tolerance for risk, self-assessed attractiveness to exploit (are you a large retailer?), your budget to upgrade, your timeline to upgrade, and other competing business priorities. In a follow-up to that we’ll discuss Drupal 7 vs. Drupal 8 decision-making (or not Drupal at all!). If we make it to part 5, we’ll wrap it up with a bang!