One of the really interesting and scary things about this month's Drupal issue is how fast the hackers moved.

Hackers moved faster than the vast majority of site-owners could respond.

It took a lot of courage for the security team to say this, but anyone whose site didn't update between 4 pm and 11 pm UTC (London time) on October 15th should assume they were hacked. That timeframe is outside of normal working hours for everyone from Paris to Tokyo.

My guess is anyone on a big name Drupal host (Acquia, Pantheon, BlackMesh etc.) is safe because those companies rolled out fixes quickly

But if your site is on an average hosting service and you didn't respond inside 7 hours, you may be in trouble.

Next time will be worse

So your Drupal site was updated in time?

Congratulations. You were probably using an expensive host. If not, you were probably in the Americas or Britain, weren't being distracted by other work and didn't have any layers of red tape to cut through before applying patches.

But what about next time? This time hackers saw the Drupal security hole and hit it very fast and hard. Next time they will likely be faster and have better tools. Next time it could be a Joomla hack inside 5 hours or a phpBB3 hack inside 3 hours.

So what can open source users and projects do in a world where attacks happen so fast? What we can do if the hackers respond faster than we can?

I believe the only solution capable of meeting this new challege are automatic updates.

2 things for open source users to do

Choose hosts that provide auto-updates: Right now, the best thing you can do is get yourself to a host that automatically rolls out security fixes. If your host didn't automatically update you this time, you should leave. Choose software that provides auto-updates: The next time you choose a new software platform, choose one that will roll out automatic security updates.

2 things for open source projects to do

Provide auto-updates: Software projects must start to automatically push out security updates to all sites that don't expressly disable that feature. This is absolutely the only way to guarantee that most sites are safe. WordPress has proven that this can be done. There are now no excuses. It's not an exaggeration to say that projects now have a window of opportunity and the incentive to make this happen. Fast forward to 2016: plenty of projects will have solved this problem and it will be hard to recommend those that haven't. Work with the largest number of hosts: Auto-updates are hard for projects to build and will take time to implement. In the short-term, projects could defend themselves by working with the largest possible group of trusted hosts. Perhaps they should also publicize that list of trusted hosts.

Conclusion

Auto-update or die.

That maxim now applies for both websites and projects.

On a good day, only 25% of Drupal, WordPress and Joomla sites are up-to-date. Now even the most responsible users can't move quickly enough to keep up.

This event has changed the game for all of us. Our current solutions rely on individual site-owners and they are no longer enough. Auto-updates are the only tool we have that can keep a very large number of sites safe, in a few hours or less, across multiple hosting platforms.