Massive Security Hole for Drupal 7 a Nightmare for Project Managers and Developers
It’s been an awful year for security for the opensource world, Heartbleed, Poodle, Shell Shock and now Drupal’s SQL Injection. Considering the fact that project managed dozens of Drupal 7 launches over the past year the latter security issue has had the largest affect on me.
From a Project and Production Management perspective security breaches are unplanned work that should take your teams top priority. Not doing so could turn into a giant PR nightmare, and turn a project completely on it’s head. However they can easily throw a wrench in productivity.
Depending on the project it can be easier when the security issue isn’t the application that’s being developed because we’re going to rely on SysAdmin or a package maintainer to provide the fixes.
The big security announcement was released on on October 15, 2014 at 4:02pm UTC had to be applied in 7 hours before the onslaught of automated attacks began. For my team that was the middle of day when the release was announced. Trying to roll out a patch in a multisite instance in the middle of the day can be tedious especially during critical operations of both a project and sites with heavy traffic. In particular, it can be brutal when there’s core patch that affects the database ops.
Even good due diligence didn’t save most of the Drupal community from being hacked. It’s been a truly rough day when a patches have to be applied almost instantaneously. The PR damage is done, and it’s probably going to be a serious issue for those considering a new project using Drupal.
For me it’s a bit scary knowing the number of Drupal sites out there, and that anyone of them can be ticking time bomb. An attacker could have placed a small backdoor, allowing them to come back later. The backdoor could be small, making it easy to miss, because the nature of the security hole it’s a manual review process.
That’s all for now and I can only hope the security hole trend, goes downwards.