The Roadmap

The goal is to reach beta quality for next European AppSec 2009, in Cracow. In order to reach this, the roadmap will be the following:

 Project roadmap v1.0_20081215
 * 16 Dec 2008, the project officialy starts
 * 16-20 Dec 2008, "Spread the voice". Each major in topic mailing list will be reached with a press announcement mail in order to find contributors
 * 21-31 Dec 2008, "The quite before the storm". During these 10 days, people in the mailing list will start discussing, sharing the first 
    ideas over the first Top 10 draft
 * 1 Jan 2009 - 31 March 2009, "Let's work". The Top 10 draft will be discussed, modified, reorganized. People from all over the world will hack 
    over it. They will destroy my first ideas, rebuilding from scratch, making examples, destroying again and rebuilding yet another time.
 * 1 April 2009, "Let's cheat". April fool, we will announce our first major release with a nonsense Top 10 :-)
 * 2 April 2009 - 15 April 2009, "Let's freeze it". Top 10 Beta will be freezed. No major updates will be possible, just minor issues or some example
    corrections.
 * 16 April 2009 - 30 April 2009, "Let's correct thesp0nge's poor english". Over the final document wiki pages, we will correct english grammar to make
    the document readable for a mother tongue person.
 * 1 May 2009 - 5 May 2009, "Let's build the doc". The final Wiki will be translated in a Microsoft Word Owasp Templated based document.
 * 6, 7 May 2009, "Let's make available for printing". The final Microsoft Word document will be sent to lulu.com for printing it.
 * 10 May 2009, "Let's announce it". Each major in topic mailing list will be reached with a press release announcement for the final document
 * 13 May 2009, "Let's release it". The first beta version of the Owasp source flaws Top 10 document will be released in Cracow, Poland during 
    upcoming Owasp AppSec Eu 2009

The Deliverable

This project deliverable will be a document with an outline very close to the "Owasp Top 10" one. For each flaw category a document chapter will be dedicated. Each chapter will be organized this way:

• Vulnerability description. Each flaw category will be in depth described in order to explain why it is a security issue for a software not to be compliant with it.
• Check list. Given a vulnerability, a non exhaustive list of security checks that can be assigned to this category it will be issued. To each check, it will be provided using 2 or 3 web oriented programming language some example about:
  • broken code
  • correct code
• Static to Dynamic bridge. When appliable, each category will be linked to the related Owasp Top 10 category
• Links. Some link to existing material.

Category naming convention

While, the Original Owasp Top 10 use the prefix "A" to introduce each category id-code (A1, ..., A10), the Source code flaws Top 10 will use the "C" letter, as "Code". So the categories will be introduced by these id codes: C1, C2, ..., C10