Much has been said about last month's highly critical Drupal security issue 'SA-CORE-2014-005', otherwise known as 'Drupalgeddon'. It was covered by mainstream international media, even if the reaction needs addressing. Drupal's security team take a responsible approach to security issues - being open & honest in disclosing them with fixes, in keeping with the community values. Security issues should always be expected in any software, it's how they are dealt with that speaks far more.
We patched all the sites that we had access to immediately fix, and informed all our clients of the issue as soon as possible. If you host a Drupal site, and haven't yet, run through the Drupalgeddon workflow right now.
Security problems will always prey on the weakest links in any software, so it's absolutely imperative that good practice is followed to mitigate for any unforeseen security holes. One of the main routes that hackers could follow to take advantage of SA-CORE-2014-005 depended on the webserver having write access to websites' webroot files & directories. As standard, we do not allow this in our servers, so the number of avenues for any hacker to follow is immediately restricted. While this has been our practice for a long time, it is moments like this that show how careful security planning is well worth it.
Hosting sites on shared servers is another avenue that can potentially be insecure - once one site is compromised, it can only be a matter of time before the others can be too. But sharing servers is very useful too, so how can sites be protected from each other? Many of our sites are hosted using Aegir, which manages file permissions and database access for us, keeping each website using separate database users, so each site's database is isolated from others on the server. Further, those database credentials are not accessible from other sites hosted on the same server. Our team has been involved in the Aegir project, helping us to learn and contribute to best deployment practices.
Modern websites are often complex and require fitting several infrastructure components together (a filesystem, SQL based databases, LAMP stack, Varnish, Solr, etc), with our Drupal sites being great examples of this. It's essential to have ability to backup, rollback, patch and do just about any operation behind the scenes securely. Revision control for the codebase (we use Git) is essential to allow quick fixing, multiple development workstreams and a clear canonical record of what the codebase 'should' be. Git would help us identify and remove any malicious files that hackers might try and add to our codebases even if they managed to ever get access. Aegir allows us to easily re-deploy sites (e.g. codebase and database backups). Again, following good practice allows us to protect against, mitigate for, and resolve potential issues immediately.
Many of our projects have undergone security reviews by outside parties, and we have plenty of experience in building secure websites. You may be interested in our Drupal services in the UK, including our own security review offering. We regularly review our own code internally, writing secure code to high standards, and we have faith that managed correctly, Drupal is a secure platform to build on. Good practice is the key to creating future-proof, feature-rich, maintainable, engaging websites. Easier said than done of course!