Projects/OWASP Periodic Table of Vulnerabilities/Roadmap - Revision history

James Landis: Updated roadmap dates

2013-07-23T18:01:30Z

Updated roadmap dates

Jmanico at 21:04, 12 March 2013

2013-03-12T21:04:50Z

Jmanico at 21:04, 12 March 2013

2013-03-12T21:04:34Z

James Landis at 03:31, 27 February 2013

2013-02-27T03:31:15Z

Samantha Groves: 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..."

2012-11-09T22:53:23Z

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..."

New page

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.

@@ Line 32: / Line 32: @@
 Complete drafts, open for peer review and comment
-== August 15, 2013 ==
+== August 30, 2013 ==
 Close comment period, begin final editing process
-== September 15, 2013 ==
+== September 30, 2013 ==
 Release v1.0 documents
@@ Line 44: / Line 44: @@
 Draft presentation materials for OWASP USA 2013
-== November 2013 ==
+== November 20, 2013 ==
 Present 1.0 draft at OWASP USA

← Older revision		Revision as of 21:04, 12 March 2013
Line 2:		Line 2:
	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).		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.	+	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.

← Older revision		Revision as of 21:04, 12 March 2013
Line 2:		Line 2:
	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).		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.	+	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.

← Older revision		Revision as of 03:31, 27 February 2013
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.