Heine

I've herd it said more than once, it won't happen to me. I know a few people who don't attempt to follow security because they don't think their sites will get hit.

Another reason I commonly hear is that it's a pain to do and the developers are just lazy.

I've, recently, found a number of people developing drupal modules who don't really know how to develop. I give them a lot of credit for trying to learn but they aren't already developers and they can't find much teaching them how to do it. I couldn't find much either. And, after talking to a couple CS graduates who do web development, I learned a lot CS students aren't learning this stuff either.

Heine, personally I read the news about the #8 position as: the Drupal security team is doing an awesome job!

But how to improve the situation?

1. Spread the word - think Drupal Tough Love, but aimed specifically at writing secure code. Give examples from the real world. Write about securely written modules, write about bad modules, write about actual vulnerabilities found in modules. And publish them on Drupal Planet.
2. Enable good behavior - promote coder module. Extend coder module's secure code review capabilities.
3. Expose bad behavior - start a security group on groups.drupal.org. Each member randomly picks 5 contributed modules, runs them through coder module, and publishes the results. Publish a top 10.
4. Or even better: (adjust and) run coder module automatically on all contributed modules in cvs, and publish or email the results to the maintainers.

It actually makes me feel good that Drupal's in this list. That's partly due to the security team doing a great job in an environment that you described in your article. Thank you for this work.

Yet, I get where you're going at. Many of the security disclosures wouldn't happen if they didn't exist in the first place.

Could http://drupal.org/writing-secure-code need an update?

And could the link to this page from http://drupal.org/node/508 "Module developer's guide" be on a more prominent place?

In addition, could there be a standard letter with important instructions that new CVS account holders receive?

For my personal immediate action: We're having Drupal Lab in DC tonight. We will talk about security there.

In my work at a higher ed institution I field a lot of calls from other orgs within my Uni as well as from other higher ed institutions. Many of them are seeking ways to implement Drupal and most, inevitably turn to Drupal security. Many point out the large number of reported security vulnerabilities and wonder if Drupal is "safe." I respond in a couple of ways.

First, I point out that a reported vulnerability is a good thing, it means that there are lots of people actively reviewing code and finding flaws. I also point out that in general, Drupal is very responsive to vulnerability disclosures and problems get fixed quickly. It is problematic that users must task someone with monitoring Drupal announcements and perform upgrades on a somewhat regular bassis, but it's better than being exploited via undisclosed vulnerabilities.

I also like to point out that Drupal core accounts for only a very small portion of security flaws. At my institution we keep a list of "approved" modules, or third party modules that our staff have reviewed and didn't find any flaws in (I emphasize that this isn't a guarantee that the modules are safe, just that they've been reviewed). We share this list and lots of contacts feel relieved by this notion and use only modules that we've vetted for security.

Perhaps if the Drupal security team were to "certify" certain modules that might reduce the number of reported security flaws (as the security team would find them proactively) and also assure customers that as long as they were using Drupal core and certified modules that their chances of being exposed to a security issue would be reduced.