I started using Drupal in the summer of 2005. My community needed a new website to share information about our meetings, and I wanted to make it a site where everyone could add information. A year and a half later, I was enmeshed in the community wherever I could be. I was addicted to helping make the Drupal software better, and I enjoyed learning about new technologies and issues related to web development. After posting a security-related item on my blog and stepping in to help out with a vulnerability in the Pathauto module, I was invited to join the security team.
At first, my role on the team was largely related to administrative tasks: helping track issues reported to the team, coordinating efforts by contributed module maintainers, and confirming bugs reported to the team or patches that would potentially be used to fix bugs. Over time I learned to recognize security weaknesses in Drupal modules and found a few weaknesses.
In 2007 at Drupalcon Barcelona, the security team was feeling particularly overwhelmed. We decided that we could not simply be reactive and fix bugs as they were reported. There were simply too many bug reports coming in for us to sustainably handle the problems. So we set about on two proactive courses:
To improve the API so that it more consistently protects users by default
To educate our community on how to write secure code so that the modules available on drupal.org would be more likely to be safe from the beginning
I worked primarily on updating and writing documentation and spreading knowledge about security at conferences and meetings.
In 2008, I was approached by Wiley to write this book and of course leapt at the opportunity. While the documentation on drupal.org is of high quality, a single person assisted by multiple editors in assembling a comprehensive, coherent book can produce a better outcome (being paid to do that work helps, too!).
Was this article helpful?