When discussing the benefits of open-source frameworks (especially Drupal), I've often heard, "But if everyone has access to the source code, how secure can it possibly be?" My standard response would be to discuss the platforms maturity and how it's been hardened by years of real world use.
But that only hints at THE critical component – the community of developers who dedicate their time and considerable talents to making Drupal an enterprise level application. From all the developers who write and maintain third party modules, to those who are are members of the core team, this community is the heart and soul of the Drupal.
And as luck (and Dylan's skill) would have it, one of our team members was recently nominated to become a full fledged member of the Drupal Security team. I sat down with Dylan to learn more about what membership on the Security team means.
Sam: How did you get invited onto the team?
Dylan: As a personal project, I had set a goal of finding 30 vulnerabilities in 30 days.
I started thinking about patterns of mistakes that are easy to make. (Access to secret information, users should only be allowed to use the system in the way it was designed to be used, not being able to degrade the site for someone, etc.) I then downloaded all the modules and grepped through them for the kinds of patterns that might mean a mistake. That mean reading a lot of code and ruling out a lot of candidates.
I had been starting to report a lot of issues and then was invited by one of current security team members and asked if I wanted to apply. I really approached it like a job interview - the whys and hows of my interest, with examples of some of the other work I had contributed to the community.
What does inclusion on the team mean?
Potential security issues are reported by the community of users. Each week, one person from the team is responsible for reading the emails that come in and assigning them to team members. After the issue has been verified, you typically start by contacting the module authors and having them fix. The team doesn't try to fix other people's code unless absolutely necessary.
What about critical vulnerabilities?
The guideline is "responsible disclosure". Submission, identify a fix, then craft a disclosure/announcement.
We also try to improve core security in ways that go beyond fixing a particular vulnerability. Things like the stronger password hashing in D7. Security team members drive that process.
How do you judge what's a security issue?
That's based on comparing the submitted report to published coding standards
and a review of other extant issues.
What's next?
Getting up to speed and beginning to work on issues that are assigned to me.
My thanks to Dylan for sitting down with me. It's quite a feather in his cap and the whole Metal Toad team is looking forward to big things.