Top 10 2013-What's Next for Verifiers - Revision history

T.Gigler: added '|year=2013 |language=en' at Top/BottomTemplates and internationalized |next= and prev=

2013-06-14T21:34:31Z

added '|year=2013 |language=en' at Top/BottomTemplates and internationalized |next= and prev=

Neil Smithline at 15:48, 14 June 2013

2013-06-14T15:48:42Z

T.Gigler: Changed use of Template 'Top_10_2010:SubsectionAdvancedTemplate': Replace Parameter 'number' by 'subsection' and 'position'

2013-04-14T09:26:46Z

Changed use of Template 'Top_10_2010:SubsectionAdvancedTemplate': Replace Parameter 'number' by 'subsection' and 'position'

Neil Smithline at 03:35, 9 March 2013

2013-03-09T03:35:38Z

Neil Smithline at 03:35, 9 March 2013

2013-03-09T03:35:12Z

Neil Smithline at 04:53, 8 March 2013

2013-03-08T04:53:48Z

Neil Smithline at 03:31, 26 February 2013

2013-02-26T03:31:17Z

Neil Smithline: moved Top 10 2013-What's Next for Validators to Top 10 2013-What's Next for Verifiers

2013-02-26T03:25:41Z

moved Top 10 2013-What's Next for Validators to Top 10 2013-What's Next for Verifiers

Neil Smithline at 03:24, 26 February 2013

2013-02-26T03:24:17Z

Neil Smithline: moved Top 10 2013-+V to Top 10 2013-What's Next for Validators

2013-02-26T03:18:55Z

moved Top 10 2013-+V to Top 10 2013-What's Next for Validators

@@ Line 1: / Line 1: @@
 {{Top_10_2013:TopTemplate
      |usenext=2013NextLink
-     |next=What's Next for Organizations
+     |next={{Top_10:LanguageFile|text=whatsNextforOrganizations|language=en}}
      |useprev=2013PrevLink
-     |prev=What's Next for Developers
+     |prev={{Top_10:LanguageFile|text=whatsNextforDevelopers|language=en}}
 }}
-{{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=freetext|position=firstWhole|title={{Top_10:LanguageFile|text=getOrganized}}|year=2013}}
+{{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=freetext|position=firstWhole|title={{Top_10:LanguageFile|text=getOrganized|language=en}}|year=2013|language=en}}
 To verify the security of a web application you have developed, or one you are considering purchasing, OWASP recommends that you review the application’s code (if available), and test the application as well. OWASP recommends a combination of secure code review and application penetration testing whenever possible, as that allows you to leverage the strengths of both techniques, and the two approaches complement each other. Tools for assisting the verification process can improve the efficiency and effectiveness of an expert analyst. OWASP’s assessment tools are focused on helping an expert become more effective, rather than trying to automate the analysis process itself.
@@ Line 14: / Line 16: @@
-{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=freetext|position=left|title={{Top_10:LanguageFile|text=codeReview}}|year=2013}}
+{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=freetext|position=left|title={{Top_10:LanguageFile|text=codeReview|language=en}}|year=2013}}
 Secure code review is particularly suited to verifying that an application contains strong security mechanisms as well as finding issues that are hard to identify by examining the application’s output. Testing is particularly suited to proving that flaws are actually exploitable. That said, the approaches are complementary and in fact overlap in some areas.
@@ Line 22: / Line 24: @@
 There are other free, open source, code review tools. The most promising is [http://findbugs.sourceforge.net/index.html  FindBugs], and its new security focused plugin called: [http://h3xstream.github.com/find-sec-bugs/  FindSecurityBugs], both of which are for Java.
-{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}||subsection=freetext|position=right|title={{Top_10:LanguageFile|text=securityAndPenetrationTesting}}|year=2013}}
+{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=freetext|position=right|title={{Top_10:LanguageFile|text=securityAndPenetrationTesting|language=en}}|year=2013}}
 Testing the Application: OWASP produced the [https://www.owasp.org/index.php/OWASP_Testing_Project  Testing Guide] to help developers, testers, and application security specialists understand how to efficiently and effectively test the security of web applications. This enormous guide, which had dozens of contributors, provides wide coverage on many web application security testing topics. Just as code review has its strengths, so does security testing. It’s very compelling when you can prove that an application is insecure by demonstrating the exploit. There are also many security issues, particularly all the security provided by the application infrastructure, that simply cannot be seen by a code review, since the application is not providing all of the security itself.
@@ Line 30: / Line 32: @@
      |type={{Top_10_2010:StyleTemplate}}
      |usenext=2013NextLink
-     |next=What's Next for Organizations
+     |next={{Top_10:LanguageFile|text=whatsNextforOrganizations|language=en}}
      |useprev=2013PrevLink
-     |prev=What's Next for Developers
+     |prev={{Top_10:LanguageFile|text=whatsNextforDevelopers|language=en}}
 }}

@@ Line 7: / Line 7: @@
 {{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=freetext|position=firstWhole|title={{Top_10:LanguageFile|text=getOrganized}}|year=2013}}
-To verify the security of a web application you have developed, or one you are considering purchasing, OWASP recommends that you review the application’s code (if available), and test the application as well. OWASP recommends a combination of security code review and application penetration testing whenever possible, as that allows you to leverage the strengths of both techniques, and the two approaches complement each other. Tools for assisting the verification process can improve the efficiency and effectiveness of an expert analyst. OWASP’s assessment tools are focused on helping an expert become more effective, rather than trying to automate the analysis process itself.
+To verify the security of a web application you have developed, or one you are considering purchasing, OWASP recommends that you review the application’s code (if available), and test the application as well. OWASP recommends a combination of secure code review and application penetration testing whenever possible, as that allows you to leverage the strengths of both techniques, and the two approaches complement each other. Tools for assisting the verification process can improve the efficiency and effectiveness of an expert analyst. OWASP’s assessment tools are focused on helping an expert become more effective, rather than trying to automate the analysis process itself.
 Standardizing How You Verify Web Application Security: To help organizations develop consistency and a defined level of rigor when assessing the security of web applications, OWASP has produced the OWASP [https://www.owasp.org/index.php/ASVS  Application Security Verification Standard (ASVS)]. This document defines a minimum verification standard for performing web application security assessments. OWASP recommends that you use the ASVS as guidance for not only what to look for when verifying the security of a web application, but also which techniques are most appropriate to use, and to help you define and select a level of rigor when verifying the security of a web application. OWASP also recommends you use the ASVS to help define and select any web application assessment services you might procure from a third party provider.
-Assessment Tools Suite: The [https://www.owasp.org/index.php/Category:OWASP_Live_CD_Project  OWASP Live CD Project] has pulled together some of the best open source security tools into a single bootable environment. Web developers, testers, and security professionals can boot from this Live CD and immediately have access to a full security testing suite. No installation or configuration is required to use the tools provided on this CD.
+Assessment Tools Suite: The [https://www.owasp.org/index.php/Category:OWASP_Live_CD_Project  OWASP Live CD Project] has pulled together some of the best open source security tools into a single bootable environment or virtual machine (VM). Web developers, testers, and security professionals can boot from this Live CD, or run the VM, and immediately have access to a full security testing suite. No installation or configuration is required to use the tools provided on this CD.
 {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=freetext|position=left|title={{Top_10:LanguageFile|text=codeReview}}|year=2013}}
-Reviewing the code is the strongest way to verify whether an application is secure. Testing can only prove that an application is insecure.
+Secure code review is particularly suited to verifying that an application contains strong security mechanisms as well as finding issues that are hard to identify by examining the application’s output. Testing is particularly suited to proving that flaws are actually exploitable. That said, the approaches are complementary and in fact overlap in some areas.
 Reviewing the Code: As a companion to the [https://www.owasp.org/index.php/OWASP_Guide_Project  OWASP Developer’s Guide], and the [https://www.owasp.org/index.php/OWASP_Testing_Project  OWASP Testing Guide], OWASP has produced the [https://www.owasp.org/index.php/Code_Review_Guide  OWASP Code Review Guide] to help developers and application security specialists understand how to efficiently and effectively review a web application for security by reviewing the code. There are numerous web application security issues, such as Injection Flaws, that are far easier to find through code review, than external testing.
-Code Review Tools: OWASP has been doing some promising work in the area of assisting experts in performing code analysis, but these tools are still in their early stages. The authors of these tools use them every day when performing their security code reviews, but non-experts may find these tools a bit difficult to use. These include [https://www.owasp.org/index.php/Category:OWASP_Code_Crawler  CodeCrawler], [https://www.owasp.org/index.php/Category:OWASP_Orizon_Project  Orizon], and [https://www.owasp.org/index.php/OWASP_O2_Platform  O2]. Only [https://www.owasp.org/index.php/OWASP_O2_Platform  O2] has been under active development during the past three years.
+Code Review Tools: OWASP has been doing some promising work in the area of assisting experts in performing code analysis, but these tools are still in their early stages. The authors of these tools use them every day when performing their secure code reviews, but non-experts may find these tools a bit difficult to use. These include [https://www.owasp.org/index.php/Category:OWASP_Code_Crawler  CodeCrawler], [https://www.owasp.org/index.php/Category:OWASP_Orizon_Project  Orizon], and [https://www.owasp.org/index.php/OWASP_O2_Platform  O2]. Only [https://www.owasp.org/index.php/OWASP_O2_Platform  O2] has been under active development since the last release of the Top 10 in 2010
 There are other free, open source, code review tools. The most promising is [http://findbugs.sourceforge.net/index.html  FindBugs], and its new security focused plugin called: [http://h3xstream.github.com/find-sec-bugs/  FindSecurityBugs], both of which are for Java.
 {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}||subsection=freetext|position=right|title={{Top_10:LanguageFile|text=securityAndPenetrationTesting}}|year=2013}}
-Testing the Application: OWASP produced the [https://www.owasp.org/index.php/OWASP_Testing_Project  Testing Guide] to help developers, testers, and application security specialists understand how to efficiently and effectively test the security of web applications. This enormous guide, which had dozens of contributors, provides wide coverage on many web application security testing topics. Just as code review has its strengths, so does security testing. It’s very compelling when you can prove that an application is insecure by demonstrating the exploit. There are also many security issues, particularly all the security provided by the application infrastructure, that simply cannot be seen by a code review, since the application is not providing the security itself.
+Testing the Application: OWASP produced the [https://www.owasp.org/index.php/OWASP_Testing_Project  Testing Guide] to help developers, testers, and application security specialists understand how to efficiently and effectively test the security of web applications. This enormous guide, which had dozens of contributors, provides wide coverage on many web application security testing topics. Just as code review has its strengths, so does security testing. It’s very compelling when you can prove that an application is insecure by demonstrating the exploit. There are also many security issues, particularly all the security provided by the application infrastructure, that simply cannot be seen by a code review, since the application is not providing all of the security itself.
-Application Penetration Testing Tools: [https://www.owasp.org/index.php/WebScarab  WebScarab], which was one of the most widely used of all OWASP projects,  and the new [https://www.owasp.org/index.php/ZAP  ZAP], which now is far more popular, are both web application testing proxies. They allow security analysts to intercept web application requests, so the analyst can figure out how the application works, and then allow the analyst to submit test requests to see if the application responds securely to such requests. These tools are particularly effective at assisting an analyst in identifying XSS flaws, Authentication flaws, and Access Control flaws. [https://www.owasp.org/index.php/ZAP  ZAP] even has an [http://code.google.com/p/zaproxy/wiki/HelpStartConceptsAscan  active scanner] built in, and best of all its FREE!
+Application Penetration Testing Tools: [https://www.owasp.org/index.php/WebScarab  WebScarab], which was one of the most widely used of all OWASP projects,  and the new ZAP, which now is far more popular, are both web application testing proxies. Such tools allow security analysts and developers to intercept web application requests, so they can figure out how the application works, and then submit test requests to see if the application responds securely to such requests. These tools are particularly effective at assisting in identifying XSS flaws, Authentication flaws, and Access Control flaws. [https://www.owasp.org/index.php/ZAP  ZAP] even has an [http://code.google.com/p/zaproxy/wiki/HelpStartConceptsAscan  active scanner] built in, and best of all it’s FREE!
 {{Top_10_2013:BottomAdvancedTemplate

@@ Line 6: / Line 6: @@
 }}
-{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|title=Get Organized|number=whole|year=2013}}
+{{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=freetext|position=firstWhole|title={{Top_10:LanguageFile|text=getOrganized}}|year=2013}}
 To verify the security of a web application you have developed, or one you are considering purchasing, OWASP recommends that you review the application’s code (if available), and test the application as well. OWASP recommends a combination of security code review and application penetration testing whenever possible, as that allows you to leverage the strengths of both techniques, and the two approaches complement each other. Tools for assisting the verification process can improve the efficiency and effectiveness of an expert analyst. OWASP’s assessment tools are focused on helping an expert become more effective, rather than trying to automate the analysis process itself.
@@ Line 12: / Line 12: @@
 Assessment Tools Suite: The [https://www.owasp.org/index.php/Category:OWASP_Live_CD_Project  OWASP Live CD Project] has pulled together some of the best open source security tools into a single bootable environment. Web developers, testers, and security professionals can boot from this Live CD and immediately have access to a full security testing suite. No installation or configuration is required to use the tools provided on this CD.
-{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|title=Code Review|number=left|year=2013}}
+{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=freetext|position=left|title={{Top_10:LanguageFile|text=codeReview}}|year=2013}}
 Reviewing the code is the strongest way to verify whether an application is secure. Testing can only prove that an application is insecure.
@@ Line 22: / Line 21: @@
 There are other free, open source, code review tools. The most promising is [http://findbugs.sourceforge.net/index.html  FindBugs], and its new security focused plugin called: [http://h3xstream.github.com/find-sec-bugs/  FindSecurityBugs], both of which are for Java.
-{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|title=Security and Penetration Testing|number=right|year=2013}}
 Testing the Application: OWASP produced the [https://www.owasp.org/index.php/OWASP_Testing_Project  Testing Guide] to help developers, testers, and application security specialists understand how to efficiently and effectively test the security of web applications. This enormous guide, which had dozens of contributors, provides wide coverage on many web application security testing topics. Just as code review has its strengths, so does security testing. It’s very compelling when you can prove that an application is insecure by demonstrating the exploit. There are also many security issues, particularly all the security provided by the application infrastructure, that simply cannot be seen by a code review, since the application is not providing the security itself.

@@ Line 30: / Line 30: @@
      |type={{Top_10_2010:StyleTemplate}}
      |usenext=2013NextLink
-     |next=What's Next for Organization
+     |next=What's Next for Organizations
      |useprev=2013PrevLink
      |prev=What's Next for Developers
 }}

@@ Line 6: / Line 6: @@
 }}
-{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|title=Welcome|number=whole|year=2013}}
+{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|title=Get Organized|number=whole|year=2013}}
-Welcome to the OWASP Top 10 2013! This update broadens one of categories from the 2010 version to be more inclusive of common, important vulnerabilities, and reorders some of the others based on changing prevalence data.  It also brings component security into the spotlight by creating a specific category for this risk, pulling it out of the obscurity of the fine print of the 2010 risk A6: Security Misconfiguration.
+To verify the security of a web application you have developed, or one you are considering purchasing, OWASP recommends that you review the application’s code (if available), and test the application as well. OWASP recommends a combination of security code review and application penetration testing whenever possible, as that allows you to leverage the strengths of both techniques, and the two approaches complement each other. Tools for assisting the verification process can improve the efficiency and effectiveness of an expert analyst. OWASP’s assessment tools are focused on helping an expert become more effective, rather than trying to automate the analysis process itself.
-The OWASP Top 10 is based on risk data from 8 firms that specialize in application security, including 4 consulting companies and 4 tool vendors (2 static and 2 dynamic). This data spans over 500,000 vulnerabilities across hundreds of organizations and thousands of applications. The Top 10 items are selected and prioritized according to this prevalence data, in combination with consensus estimates of exploitability, detectability, and impact estimates.
+Standardizing How You Verify Web Application Security: To help organizations develop consistency and a defined level of rigor when assessing the security of web applications, OWASP has produced the OWASP [https://www.owasp.org/index.php/ASVS  Application Security Verification Standard (ASVS)]. This document defines a minimum verification standard for performing web application security assessments. OWASP recommends that you use the ASVS as guidance for not only what to look for when verifying the security of a web application, but also which techniques are most appropriate to use, and to help you define and select a level of rigor when verifying the security of a web application. OWASP also recommends you use the ASVS to help define and select any web application assessment services you might procure from a third party provider.
-The primary aim of the OWASP Top 10 is to educate developers, designers, architects, managers, and organizations about the consequences of the most important web application security weaknesses. The Top 10 provides basic techniques to protect against these high risk problem areas – and also provides guidance on where to go from here.
+Assessment Tools Suite: The [https://www.owasp.org/index.php/Category:OWASP_Live_CD_Project  OWASP Live CD Project] has pulled together some of the best open source security tools into a single bootable environment. Web developers, testers, and security professionals can boot from this Live CD and immediately have access to a full security testing suite. No installation or configuration is required to use the tools provided on this CD.
 </td></tr></table>
-{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|title=Warnings|number=left|year=2013}}
+{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|title=Code Review|number=left|year=2013}}
-Don’t stop at 10. There are hundreds of issues that could affect the overall security of a web application as discussed in the OWASP Developer’s Guide. This is essential reading for anyone developing web applications today. Guidance on how to effectively find vulnerabilities in web applications are provided in the OWASP Testing Guide and OWASP Code Review Guide, which have both been significantly updated since the previous release of the OWASP Top 10.
+Reviewing the code is the strongest way to verify whether an application is secure. Testing can only prove that an application is insecure.
-Constant change. This Top 10 will continue to change. Even without changing a single line of your application’s code, you may become vulnerable as new flaws are discovered. Please review the advice at the end of the Top 10 in “What’s Next For Developers, Verifiers, and Organizations” for more information.
+Reviewing the Code: As a companion to the [https://www.owasp.org/index.php/OWASP_Guide_Project  OWASP Developer’s Guide], and the [https://www.owasp.org/index.php/OWASP_Testing_Project  OWASP Testing Guide], OWASP has produced the [https://www.owasp.org/index.php/Code_Review_Guide  OWASP Code Review Guide] to help developers and application security specialists understand how to efficiently and effectively review a web application for security by reviewing the code. There are numerous web application security issues, such as Injection Flaws, that are far easier to find through code review, than external testing.
-Think positive. When you’re ready to stop chasing vulnerabilities and focus on establishing strong application security controls, OWASP has produced the Application Security Verification Standard (ASVS) as a guide to organizations and application reviewers on what to verify.
+Code Review Tools: OWASP has been doing some promising work in the area of assisting experts in performing code analysis, but these tools are still in their early stages. The authors of these tools use them every day when performing their security code reviews, but non-experts may find these tools a bit difficult to use. These include [https://www.owasp.org/index.php/Category:OWASP_Code_Crawler  CodeCrawler], [https://www.owasp.org/index.php/Category:OWASP_Orizon_Project  Orizon], and [https://www.owasp.org/index.php/OWASP_O2_Platform  O2]. Only [https://www.owasp.org/index.php/OWASP_O2_Platform  O2] has been under active development during the past three years.
-Use tools wisely. Security vulnerabilities can be quite complex and buried in mountains of code. In many cases, the most cost-effective approach for finding and eliminating these weaknesses is human experts armed with good tools.
+There are other free, open source, code review tools. The most promising is [http://findbugs.sourceforge.net/index.html  FindBugs], and its new security focused plugin called: [http://h3xstream.github.com/find-sec-bugs/  FindSecurityBugs], both of which are for Java.
-Push left. Focus on making security an integral part of your culture throughout your development organization. Find out more in the Open Software Assurance Maturity Model (SAMM) and the Rugged Handbook.
+Application Penetration Testing Tools: [https://www.owasp.org/index.php/WebScarab  WebScarab], which was one of the most widely used of all OWASP projects,  and the new [https://www.owasp.org/index.php/ZAP  ZAP], which now is far more popular, are both web application testing proxies. They allow security analysts to intercept web application requests, so the analyst can figure out how the application works, and then allow the analyst to submit test requests to see if the application responds securely to such requests. These tools are particularly effective at assisting an analyst in identifying XSS flaws, Authentication flaws, and Access Control flaws. [https://www.owasp.org/index.php/ZAP  ZAP] even has an [http://code.google.com/p/zaproxy/wiki/HelpStartConceptsAscan  active scanner] built in, and best of all its FREE!
 {{Top_10_2013:BottomAdvancedTemplate

@@ Line 6: / Line 6: @@
 }}
-{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=left|title=Forward|year=2013}}
+{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|title=Welcome|number=whole|year=2013}}
-Insecure software is undermining our financial, healthcare, defense, energy, and other critical infrastructure. As our digital infrastructure gets increasingly complex and interconnected, the difficulty of achieving application security increases exponentially. We can no longer afford to tolerate relatively simple security problems like those presented in this OWASP Top 10.
+Welcome to the OWASP Top 10 2013! This update broadens one of categories from the 2010 version to be more inclusive of common, important vulnerabilities, and reorders some of the others based on changing prevalence data.  It also brings component security into the spotlight by creating a specific category for this risk, pulling it out of the obscurity of the fine print of the 2010 risk A6: Security Misconfiguration.
-The goal of the Top 10 project is to raise awareness about application security by identifying some of the most critical risks facing organizations. The Top 10 project is referenced by many standards, books, tools, and organizations, including MITRE, PCI DSS, DISA, FTC, and many more. This release of the OWASP Top 10 marks this project’s eleventh year of raising awareness of the importance of application security risks. The OWASP Top 10 was first released in 2003, with minor updates in 2004 and 2007. The 2010 version was revamped to prioritize by risk, not just prevalence. This 2013 edition follows the same approach.
+The OWASP Top 10 is based on risk data from 8 firms that specialize in application security, including 4 consulting companies and 4 tool vendors (2 static and 2 dynamic). This data spans over 500,000 vulnerabilities across hundreds of organizations and thousands of applications. The Top 10 items are selected and prioritized according to this prevalence data, in combination with consensus estimates of exploitability, detectability, and impact estimates.
-We encourage you to use the Top 10 to get your organization started with application security. Developers can learn from the mistakes of other organizations. Executives should start thinking about how to manage the risk that software applications create in their enterprise.
+The primary aim of the OWASP Top 10 is to educate developers, designers, architects, managers, and organizations about the consequences of the most important web application security weaknesses. The Top 10 provides basic techniques to protect against these high risk problem areas – and also provides guidance on where to go from here.
-In the long term, we encourage you to create an application security program that is compatible with your culture and technology. These programs come in all shapes and sizes, and you should avoid attempting to do everything in a process model. Instead, leverage your existing organization’s strengths and measure what works for you.
+{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|title=Warnings|number=left|year=2013}}
-We hope that the OWASP Top 10 is useful to your application security efforts. Please don’t hesitate to contact OWASP with your questions, comments, and ideas, either publicly to owasp-topten@lists.owasp.org or privately to dave.wichers@owasp.org.
+Constant change. This Top 10 will continue to change. Even without changing a single line of your application’s code, you may become vulnerable as new flaws are discovered. Please review the advice at the end of the Top 10 in “What’s Next For Developers, Verifiers, and Organizations” for more information.
-{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|number=right|title=About OWASP|year=2013}}
+Think positive. When you’re ready to stop chasing vulnerabilities and focus on establishing strong application security controls, OWASP has produced the Application Security Verification Standard (ASVS) as a guide to organizations and application reviewers on what to verify.
-The Open Web Application Security Project (OWASP) is an open community dedicated to enabling organizations to develop, purchase, and maintain applications that can be trusted.  At OWASP you’ll find free and open …
+Use tools wisely. Security vulnerabilities can be quite complex and buried in mountains of code. In many cases, the most cost-effective approach for finding and eliminating these weaknesses is human experts armed with good tools.
-* Application security tools and standards
+Push left. Focus on making security an integral part of your culture throughout your development organization. Find out more in the Open Software Assurance Maturity Model (SAMM) and the Rugged Handbook.
-All of the OWASP tools, documents, forums, and chapters are free and open to anyone interested in improving application security. We advocate approaching application security as a people, process, and technology problem, because the most effective approaches to application security require improvements in all of these areas.
+{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|title=Acknowledgements|number=right|year=2013}}
-OWASP is a new kind of organization. Our freedom from commercial pressures allows us to provide unbiased, practical, cost-effective information about application security. OWASP is not affiliated with any technology company, although we support the informed use of commercial security technology. Similar to many open-source software projects, OWASP produces many types of materials in a collaborative, open way.
+We’d like to thank those organizations that contributed their vulnerability prevalence data to support the 2013 update:
+* Aspect Security
-The OWASP Foundation is the non-profit entity that ensures the project’s long-term success. Almost everyone associated with OWASP is a volunteer, including the OWASP Board, Global Committees, Chapter Leaders, Project Leaders, and project members. We support innovative security research with grants and infrastructure.
+* HP (Results for both Fortify and WebInspect)
+* Minded Security
-Come join us!
+* Softtek
+* TrustWave
-</td></tr></table>
+* Veracode – Statistics
-{{Top_10_2013:BottomTemplate
+{{Top_10_2013:BottomAdvancedTemplate
      |usenext=2013NextLink
-     |next=What's Next for Organizations
+     |next=What's Next for Organizers
      |useprev=2013PrevLink
      |prev=What's Next for Developers
 }}

← Older revision	Revision as of 03:25, 26 February 2013
(No difference)

← Older revision		Revision as of 03:24, 26 February 2013
Line 1:		Line 1:
−	~~effectiveness~~	+	{{Top_10_2013:TopTemplate
		+	\|usenext=2013NextLink
		+	\|next=What's Next for Organizations
		+	\|useprev=2013PrevLink
		+	\|prev=What's Next for Developers
		+	}}
		+
		+	{{Top_10_2010:SubsectionAdvancedTemplate\|type={{Top_10_2010:StyleTemplate}}\|number=left\|title=Forward\|year=2013}}
		+	Insecure software is undermining our financial, healthcare, defense, energy, and other critical infrastructure. As our digital infrastructure gets increasingly complex and interconnected, the difficulty of achieving application security increases exponentially. We can no longer afford to tolerate relatively simple security problems like those presented in this OWASP Top 10.
		+
		+	The goal of the Top 10 project is to raise awareness about application security by identifying some of the most critical risks facing organizations. The Top 10 project is referenced by many standards, books, tools, and organizations, including MITRE, PCI DSS, DISA, FTC, and many more. This release of the OWASP Top 10 marks this project’s eleventh year of raising awareness of the importance of application security risks. The OWASP Top 10 was first released in 2003, with minor updates in 2004 and 2007. The 2010 version was revamped to prioritize by risk, not just prevalence. This 2013 edition follows the same approach.
		+
		+	We encourage you to use the Top 10 to get your organization started with application security. Developers can learn from the mistakes of other organizations. Executives should start thinking about how to manage the risk that software applications create in their enterprise.
		+
		+	In the long term, we encourage you to create an application security program that is compatible with your culture and technology. These programs come in all shapes and sizes, and you should avoid attempting to do everything in a process model. Instead, leverage your existing organization’s strengths and measure what works for you.
		+
		+	We hope that the OWASP Top 10 is useful to your application security efforts. Please don’t hesitate to contact OWASP with your questions, comments, and ideas, either publicly to owasp-topten@lists.owasp.org or privately to dave.wichers@owasp.org.
		+
		+	{{Top_10_2010:SubsectionAdvancedTemplate\|type={{Top_10_2010:StyleTemplate}}\|number=right\|title=About OWASP\|year=2013}}
		+
		+	The Open Web Application Security Project (OWASP) is an open community dedicated to enabling organizations to develop, purchase, and maintain applications that can be trusted. At OWASP you’ll find free and open …
		+
		+	* Application security tools and standards
		+	* Complete books on application security testing, secure code development, and security code review
		+	* Standard security controls and libraries
		+	* Local chapters worldwide
		+	* Cutting edge research
		+	* Extensive conferences worldwide
		+	* Mailing lists
		+	* And more … all at www.owasp.org/
		+	* Including: www.owasp.org/index.php/Top_10
		+
		+	All of the OWASP tools, documents, forums, and chapters are free and open to anyone interested in improving application security. We advocate approaching application security as a people, process, and technology problem, because the most effective approaches to application security require improvements in all of these areas.
		+
		+	OWASP is a new kind of organization. Our freedom from commercial pressures allows us to provide unbiased, practical, cost-effective information about application security. OWASP is not affiliated with any technology company, although we support the informed use of commercial security technology. Similar to many open-source software projects, OWASP produces many types of materials in a collaborative, open way.
		+
		+	The OWASP Foundation is the non-profit entity that ensures the project’s long-term success. Almost everyone associated with OWASP is a volunteer, including the OWASP Board, Global Committees, Chapter Leaders, Project Leaders, and project members. We support innovative security research with grants and infrastructure.
		+
		+	Come join us!
		+
		+	</td></tr></table>
		+
		+	{{Top_10_2013:BottomTemplate
		+	\|usenext=2013NextLink
		+	\|next=What's Next for Organizations
		+	\|useprev=2013PrevLink
		+	\|prev=What's Next for Developers
		+	}}
		+	[[Category:OWASP Top Ten Project]]

← Older revision	Revision as of 03:18, 26 February 2013
(No difference)