The Open Source Drupal Content Management System (CMS) has been hit with a series of vulnerabilities in the first months of 2018. The four distinct security releases (SA-CORE-2018-001, SA-CORE-2018-002, SA-CORE-2018-003, SA-CORE-2018-004) have all been labelled critical or highly critical.
All of these issues that are in place have been in the core distribution system, and not in the third party plugins known as modules in Drupal. These third party modules are often not well maintained and can propose serious security risks in themselves. For the core updates, the Drupal Security Team, has done an admirable job of patching and maintaining the core software popular in enterprise settings.
But it seems that at the rate of vulnerabilities uncovered in the most popular Drupal 7.x and 8.x versions is increasing. These vulnerabilities are also exploited at an ever faster release cycle, meaning that without a robust auto updating system, the vast majority of Drupal sites will be vulnerable to exploits. In the case of the most recent "Drupalgeddon 3" incident exploits were in place in a matter of hours of the release of the patch.
A majority professional Drupal support organisations don't respond in hours, if it outside of office hours. This means that there is an ever increasing possibility of critical vulnerabilities being exploited, but not necessarily ever uncovered. It is worth noting that software always has issues. The most valuable of them are "zero days", where there are no patches at all. This is a popular term from the desktop world of Windows Operating System, but online software like Drupal is always online and thus always vulnerable to zero day exploits.
To add to the complexity, the security patches themselves can expose new attack vectors. When done in a rush and without proper preparations in an intense situation, developers are more prone to making errors. This is why hasted patches (and patch applications) can contain more vulnerabilities. And with the focus of fixes available via the source code to malicious parties, it is likely that these areas will be even more interesting in the future. An old codebase may be considered robust, but it also has it's fair bit of rot - rot that can be exploited by operators working for criminal organisations, competitors or even state actors.
When choosing an IT system the recent track record for fixes is always a good point to start. Drupal has not had a good few months, but unless major discoveries are made and widely exploited - the project still has a chance of salvaging the project. Instead of focusing on a navigation redesign, Acquia, the enterprise sponsor of the project, should invest heavily in plugging any holes in the architecture of Drupal.
Microsoft managed to improve security in Windows XP in the early 2000's, and Drupal should be able to do the same with an automated system and architectural improvements. But up until that effort materialises, there is always a doubt on how secure your 24/7/365 connected business critical application built on Drupal is.