How to most effectively beat a dead horse...

The trend of Month of Bugs continues unabated. Lets look at the history and get my arm chair analyst commentary:

• Month of Browser Bugs
• Leader: HD Moore
  
• Impact: Effective, highlighted the importance of browser security and pointed out a number of noteworthy flaws in a wide range of browsers including IE, Firefox, Camino, Opera, and Safari.
• Positives: Well researched, well orchestrated, spread over multiple vendors, including some vulnerabilities that affected multiple applications.
• Negatives: Hard to say considering this one set the bar, and many since have fallen short.
  
• Site: http://browserfun.blogspot.com/
  
• Month of Kernel Bugs
• Leader: LMH
  
• Impact: Similar to MoBB. Showed that fuzzable flaws weren't purely things found in "trivial" places like browsers, but in serious places like the lowest levels of operating systems.
  
• Positives: Took on an equally, if not even more, prolific area of system security. Lots of tasty PoC code.
  
• Negatives: I didn't play with many of them myself, but I've been told some of the PoCs were a bit unreliable, not to mention many were not remotely exploitable.
  
• Site: http://kernelfun.blogspot.com/
  
• Month of Apple Bugs
• Leader: LMH and Kevin Finisterre
• Impact: Definitely the dark sheep of the "Month's" the MoAB was littered with issues. While it did expose some flaws on Apple hardware/software it did little to dissuade Mac users from a feeling of invincibility and was taken less than seriously, even by information security types. Also the first "Month" to have a concurrent project providing on the fly patches to each days bugs.
  
• Positives: Had it's sights set on a group that needed to understand their vulnerability and went after a wide spread of Mac software.
  
• Negatives: The spread was too wide. Many of the flaws found were shrugged off by Apple users as "not Apple problems" (See: PDF and VLC). Coupled with the fact that PoC was spotty and nothing was ever released about the crowning "Unspecified Kernel Remote Fun" this was thought by many to have not been worth the hype.
  
• Site: http://projects.info-pull.com/moab/
  
• Month of PHP Bugs
• Leader: Stefan Esser
  
• Impact: At first I thought this would be a joke. Vulerabilities are reported every day in various PHP based applications. What is currently making this so effective is that they're only releasing vulnerabilities in the PHP core, not the poorly written Bullitin Board applications that get reported on daily.
  
• Positives: Focused on the real security problems with PHP, not the low hanging fruit in 3rd party PHP applications.
  
• Negatives: Well... this is where that beating a dead horse comment came from. PHP can seem like the majority of all vulnerabilities reported and it can seem like more PHP vulnerabilities are just overkill. Also no word yet on if fixes will be provided.
  
• Site: http://www.php-security.org/

So what's my final take? Well, there's a place for "Months" but they're only effective if well done. What makes an effective Month? Here ya go:

• Chose a relevant technology and make sure your vulnerabilities affect it, not arbitrary related software. If you say it's Apple vulnerabilities then fuzz iTunes, not VLC.
• Going a long with the last point it's also important to deliver what you promise. If you promise a kernel level vulnerability then it better exploit the kernels. If you promise it's remote then it needs to be remote, not remote if you can social engineer someone to run it with Admin privileges.
• Give us proof of concept code, otherwise it's too easy for everyone to say you're makin' it up.
• If you break it then fix it, or at least find someone who will.
• Be fair to the vendors and be fair to the users. Dropping 30 0-days doesn't help users. Being pushed around by a vendor who doesn't wanna fix their problems doesn't help users either.

All that said I welcome the Month of PHP Bugs. While I'm not a huge fan of PHP it is an important language that makes up many sites that are used daily all over the Internet. Stefan Esser has tried to improve security in every way he can, and for my money he's now responsibly using vulnerability disclosure in a way that will hopefully encourage the PHP team to make their language more secure, and that's better for everyone.