This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "Projects/OWASP Periodic Table of Vulnerabilities/Roadmap"

From OWASP
Jump to: navigation, search
(Created page with "There is really only one clear milestone, which is to ensure that the community agrees about how each vulnerability is most efficiently solved. The Periodic Table captures tha...")
 
Line 1: Line 1:
There is really only one clear milestone, which is to ensure that the community agrees about how each vulnerability is most efficiently solved. The Periodic Table captures that agreement in an easily referenceable form. Ideally, the document will influence the direction of many other OWASP projects. For example, the Top 10 Defenses project might eventually choose to focus only on the issues that will require developer attention, or there may be different Top 10s for WAF vendors, framework developers, and browser vendors. A new project, similar to WAFEC, could also be started based on the Table which measures how well frameworks are actually meeting the requirements to address certain vulnerabilities. But once there is agreement, the Table will remain generally static, while accommodating new vulnerability research or lessons learned from trying to apply the table to real world situations.
+
 
 +
The end state of the project is to ensure that the community agrees about how each vulnerability is most efficiently eradicated. The Periodic Table captures that agreement in an easily referenceable form (or forms).
 +
 
 +
Ideally, the document will then influence the direction of many other OWASP projects and industry activities. For example, the Top 10 Defenses project might eventually choose to focus only on the issues that will require developer attention, or there may be different Top 10s for WAF vendors, framework developers, and browser vendors. A new project, similar to [[WASC_OWASP_Web_Application_Firewall_Evaluation_Criteria_Project]], could also be started based on the Table which measures how well frameworks are actually meeting the requirements to address certain vulnerabilities. Once there is agreement, the Table will remain generally static, while accommodating new vulnerability research or lessons learned from trying to apply the table to real world situations.
 +
 
 +
 
 +
== March 15, 2013 ==
 +
 
 +
Finalize list of contributors and reviewers. Seeking representatives from each of the following industries and roles:
 +
 
 +
* INDUSTRY REPRESENTATIVES
 +
** Banking / finance / insurance
 +
** E-commerce / merchant services
 +
** Health care
 +
** Browser vendors
 +
** Internet standards / governance
 +
** Application runtime testing / static analysis vendors
 +
** Web application firewall (WAF) vendors
 +
** Web application framework vendors/developers
 +
* ROLE TYPE REPRESENTATIVES
 +
** Web software developers
 +
** Web application architects
 +
** Penetration testers
 +
** Compliance owners, especially EU and international regulatory compliance
 +
 
 +
== April 15, 2013 ==
 +
 
 +
Define publication format(s) and start drafts
 +
 
 +
== May 15, 2013 ==
 +
 
 +
Complete drafts, open for peer review and comment
 +
 
 +
== August 15, 2013 ==
 +
 
 +
Close comment period, begin final editing process
 +
 
 +
== September 15, 2013 ==
 +
 
 +
Release v1.0 documents
 +
 
 +
== October 2013 ==
 +
 
 +
Draft presentation materials for OWASP USA 2013
 +
 
 +
== November 2013 ==
 +
 
 +
Present 1.0 draft at OWASP USA
 +
 
 +
== December 2013 ==
 +
 
 +
Begin measuring browser compliance, standards support, WAF support, and framework compliance against table prescriptions.

Revision as of 03:31, 27 February 2013

The end state of the project is to ensure that the community agrees about how each vulnerability is most efficiently eradicated. The Periodic Table captures that agreement in an easily referenceable form (or forms).

Ideally, the document will then influence the direction of many other OWASP projects and industry activities. For example, the Top 10 Defenses project might eventually choose to focus only on the issues that will require developer attention, or there may be different Top 10s for WAF vendors, framework developers, and browser vendors. A new project, similar to WASC_OWASP_Web_Application_Firewall_Evaluation_Criteria_Project, could also be started based on the Table which measures how well frameworks are actually meeting the requirements to address certain vulnerabilities. Once there is agreement, the Table will remain generally static, while accommodating new vulnerability research or lessons learned from trying to apply the table to real world situations.


March 15, 2013

Finalize list of contributors and reviewers. Seeking representatives from each of the following industries and roles:

  • INDUSTRY REPRESENTATIVES
    • Banking / finance / insurance
    • E-commerce / merchant services
    • Health care
    • Browser vendors
    • Internet standards / governance
    • Application runtime testing / static analysis vendors
    • Web application firewall (WAF) vendors
    • Web application framework vendors/developers
  • ROLE TYPE REPRESENTATIVES
    • Web software developers
    • Web application architects
    • Penetration testers
    • Compliance owners, especially EU and international regulatory compliance

April 15, 2013

Define publication format(s) and start drafts

May 15, 2013

Complete drafts, open for peer review and comment

August 15, 2013

Close comment period, begin final editing process

September 15, 2013

Release v1.0 documents

October 2013

Draft presentation materials for OWASP USA 2013

November 2013

Present 1.0 draft at OWASP USA

December 2013

Begin measuring browser compliance, standards support, WAF support, and framework compliance against table prescriptions.