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 "OWASP Common Numbering Project"

From OWASP
Jump to: navigation, search
 
(30 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 +
{|
 +
|-
 +
! width="700" align="center" | <br>
 +
! width="500" align="center" | <br>
 +
|-
 +
| align="right" | [[Image:OWASP Inactive Banner.jpg|800px| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Inactive_Projects]]
 +
| align="right" |
 +
 +
|}
 +
 
==== Home ====
 
==== Home ====
<table width="100%" valign="top"><tr><th width="50%"> </th><th> </th></tr><tr valign="top">
+
<table width="100%" valign="top"><tr><th width="100%"> </th><th> </th></tr><tr valign="top">
 
<td>'''Common OWASP Numbering'''
 
<td>'''Common OWASP Numbering'''
  
''An exciting development, a new numbering scheme that will be common across OWASP Guides and References has been developed. The numbering is based on the OWASP ASVS section and detailed requirement numbering. The effort to develop the numbering was a team effort, led by Mike Boberski (ASVS project lead and co-author). OWASP Top Ten, Guide, and Reference project leads and contributors as well as the OWASP leadership worked together to develop numbering that would allow for easy mapping between OWASP Guides and References, and that would allow for a period of transition as Guides and References are updated to reflect the new numbering. This project will for example track retired numbers. For more information, please contact [mailto:mike.boberski@owasp.org Mike] or [mailto:brad.causey@owasp.org Brad].  
+
An exciting development, a new numbering scheme that will be common across various OWASP Guides and References is being developed. This  numbering scheme is loosely based on the OWASP ASVS section and detailed requirements numbering. The OWASP ASVS, Guide, and Reference project leads and contributors plan to work together to develop a numbering scheme that facilitates easier mapping between various OWASP Guides and References, and that would allow for a period of transition as the Guides and References are updated to reflect the new numbering scheme. This project will provide a centralized clearinghouse for mapping information. For more information on this project, or if you wish to contribute, please contact [mailto:dave.wichers@owasp.org Dave Wichers].
 +
 
 +
This common numbering scheme will be of requirements. A mapping of vulnerabilities to this requirements list will most likely be developed after the common requirements list is created. This common numbering scheme is intended to be independent of any particular OWASP project and is not intended to dictate how those projects are developed and organized. Its intent is to be a resource to facilitate cross referencing between related topics and to encourage, but not require, projects like the OWASP Guides to adopt a similar structure. But that decision is up to the respective project leads.
 
</td>
 
</td>
<td>'''Latest News'''
+
</tr>
 +
</table>
 +
 
 +
==== OWASP Common Requirements Numbering Scheme DRAFT====
 +
<table width="100%" valign="top"><tr><th width="50%"> </th><th> </th></tr><tr valign="top">
 +
<td>'''Proposed OWASP Common Requirements Numbering Scheme Format:'''
  
* Coming soon!
+
OCR-AUTHN-01
 +
OCR-AUTHN-02
 +
OCR-AUTHN-02.01
 +
OCR-AUTHN-03
 +
OCR-INPVAL-01
 +
OCR-INPVAL-02
  
 +
Common Requirements Numbering Scheme Proposed Requirement Areas:
 +
* OCR-AUTHN: Authentication
 +
* OCR-SESS: Session Management
 +
* OCR-INPVAL: Input Validation
 +
* OCR-OUTENC: Output Encoding
 +
* OCR-AUTHZ: Functional and Data Layer Access Control
 +
* OCR-BUS: Business Logic
 +
* OCR-DATAP: Sensitive Data Protection
 +
* OCR-CRYPST: Cryptographic Storage
 +
* OCR-COMMS: Communication Security
 +
* OCR-ERROR: Error Handling
 +
* OCR-LOG: Logging
 +
* OCR-DBASE: Secure Database Usage
 +
* OCR-FILE: Secure File Access
 +
* OCR-MEM: Memory Management
 +
* OCR-GEN: General Coding Practices
 +
* OCR-CONFIG: Secure System Configuration
 +
* OCR-INTEG: Integrity
 +
* OCR-AVAIL: Availability
 +
 +
</td>
 +
<td>'''Reference'''
 +
*1st Element - Document code (OCR=OWASP Common Requirements Number, ODG=OWASP Development Guide, OTG=OWASP Testing Guide, OCG=OWASP Code Review Guide, others reserved)
 +
*2nd Element - Requirement Area (major)
 +
*3rd Element - Detailed Requirement Identifier (minor with up to one sublevel (e.g., .01, .02)
 +
*4th Element (Optional: DEPRECATED, or # for iterations, or legacy identifiers)<br>
 
</td></tr>
 
</td></tr>
 
</table>
 
</table>
  
==== Common OWASP Numbering ====
+
==== OWASP Common Requirements - DRAFT ====
Below is the generally agreed-upon new numbering scheme.
 
  
OWASP-0600
+
The following is the first section we have developed of common requirements. It is the section on Authentication (OCR-AUTHN). This is draft, and your feedback is very welcome. Please provide any feedback to [mailto:[email protected] Dave Wichers].
OWASP-0600-DEPRECATED
 
OWASP-0604
 
OWASP-0604-DEPRECATED
 
OWASP-0604-DG
 
OWASP-0604-DG-01
 
OWASP-0604-TG
 
OWASP-0604-TG-DV-005
 
OWASP-0604-TG-DV-005-DEPRECATED
 
  
  0123456789012345678901234567890123456789
+
{| class="prettytable"
          1         2        3
+
|-
 +
| <center>'''OWASP Common Number'''</center>
 +
| <center>'''Common Requirement'''</center>
 +
|-
 +
| align="center" colspan="2" | '''Authentication Requirements'''
 +
|-
 +
| OCR-AUTH-01
 +
| All authentication controls operate on a trusted system (e.g., The server).
 +
|-
 +
| OCR-AUTH-02  
 +
| Authentication is required for all pages and resources, except those specifically intended to be public.
 +
|-
 +
| OCR-AUTH-03
 +
| The application utilizes standardized, tested, and centralized authentication services.
 +
|-
 +
| OCR-AUTH-04
 +
| Authentication services utilize a centralized authentication store.
 +
|-
 +
| OCR-AUTH-05
 +
| All authentication controls fail securely.
 +
|-
 +
| OCR-AUTH-06
 +
| System configurable password strength requirements are enforced. This includes both minimum length and minimum complexity rules.
 +
|-
 +
| OCR-AUTH-07
 +
| Disallow account passwords to match any of the last N passwords for that account, where N is a system configurable value. This is done to discourage password re-use.
 +
|-
 +
| OCR-AUTH-08
 +
| Passwords must be a system configurable minimum age (e.g., one day old) before they can be changed, to prevent attacks on password re-use
 +
|-
 +
| OCR-AUTH-09
 +
| Password entry fields do not echo the user’s password when it is entered.
 +
|-
 +
| OCR-AUTH-10
 +
| Autocomplete is disabled for all password entry fields in HTML forms.
 +
|-
 +
| OCR-AUTH-11
 +
| Passwords are transmitted over an encrypted connection. Temporary passwords associated with email resets may be an exception to this rule.
 +
|-
 +
| OCR-AUTH-12
 +
| For authentication over HTTP, authentication credentials are transmitted only within the POST body and not in the URL.
 +
|-
 +
| OCR-AUTH-13
 +
| Authentication controls and application functionality minimize the leakage of user account names.
 +
|-
 +
| OCR-AUTH-14
 +
| Stored server side passwords are protected using cryptographically strong one-way salted hashes that use salts that are unique per account. (e.g., Do not use the MD5 or SHA-1 algorithms).
 +
|-
 +
|OCR-AUTH-15
 +
| Use large numbers of hash iterations or password based encryption to make it time consuming to calculate a single hashed password value.
 +
|-
 +
| OCR-AUTH-16
 +
| Stored passwords and cryptographic keys are readable and writeable only by the application.
 +
|-
 +
| OCR-AUTH-17
 +
| Brute force protection is provided after a system configurable number of invalid login attempts occur against an account within a configurable period of time (e.g., account is locked, CAPTCHA required, throttling enabled).
 +
|-
 +
| OCR-AUTH-18
 +
| Implement monitoring to identify attacks against multiple user accounts, utilizing the same password. This attack pattern is used to bypass standard lockouts, when valid user IDs can be harvested or inferred.
 +
|-
 +
| OCR-AUTH-19
 +
| The date/time of the last successful login is reported to the user after they login, along with the number of failed login attempts since the last successful login.
 +
|-
 +
| OCR-AUTH-20
 +
| Password changing mechanisms are at least as resistant to attack as the primary authentication mechanism.
 +
|-
 +
| OCR-AUTH-21
 +
| Passwords are required to be changed before they become older than a system configurable maximum age.
 +
|-
 +
| OCR-AUTH-22
 +
| Password reset questions support sufficiently random answers. (e.g., "favorite color" is a bad question because red, blue, green, are very common answers. Favorite book is another bad question that generates insufficiently random answers.).
 +
|-
 +
| OCR-AUTH-23
 +
| For email based resets, only send email to a pre-registered address with a temporary link/password. Reset questions should be asked after the user goes to the temporary page, not before the email is generated.
 +
|-
 +
| OCR-AUTH-24
 +
| Temporary passwords and links have a short, system configurable, expiration time.
 +
|-
 +
| OCR-AUTH-25
 +
| Users are required to change temporary passwords as soon as they are used.
 +
|-
 +
| OCR-AUTH-26
 +
| Users are notified when a password reset occurs on their account.
 +
|-
 +
| OCR-AUTH-27
 +
| Users must re-authenticate prior to performing security critical operations, such as change password, change email address, change mailing address, change mailing address, view very sensitive data, send funds, etc.
 +
|-
 +
| OCR-AUTH-28
 +
| All administrative and account management functions are at least as secure as the primary authentication mechanism.
 +
|-
 +
| OCR-AUTH-29
 +
| Authentication is required for services exposed to external systems that provide sensitive information or functions.
 +
|-
 +
| OCR-AUTH-30
 +
| All authentication credentials for accessing services external to the application are encrypted and stored in a protected location (e.g., not in source code).
 +
|-
 +
| OCR-AUTH-31
 +
| Multi-Factor Authentication is used for highly sensitive or high value systems or for specific high value transactions.
 +
|}
  
*0-4 OWASP
 
*6-7 Detailed requirement identifier (major)
 
*8-9 Detailed requirement identifier (minor)
 
*11-12 Document code (DG=Development Guide, TG=Testing Guide, CG=Code Review Guide, AR, ED, RM, OR, others reserved)
 
*14-40 (Optional: DEPRECATED, or # for iterations, or legacy identifiers)<br>
 
  
==== Legacy Numbering Mappings ====
+
{{{#!comment        Lets comment all this other stuff out for now.
Coming soon!
 
  
== Mapping to Legacy Testing Guide IDs  ==
+
==== Mapping to Legacy Testing Guide IDs  ====
  
{| class="prettytable"
+
Note: This is still a work in progress and is currently incomplete.
|-
+
 
 +
{class="prettytable" <-- this needs a pipe character in front of class to work. I had to remove it because it was causing this line to be displayed even though this entire block is commented out.
 +
|
 
| <center>'''Ref. Number'''</center>  
 
| <center>'''Ref. Number'''</center>  
 
| <center>'''Test Name'''</center>  
 
| <center>'''Test Name'''</center>  
Line 330: Line 463:
 
|}
 
|}
  
== Mapping to Top 10 2010 IDs  ==
+
==== Mapping to Top 10 2010 IDs  ====
  
{| class="prettytable"
+
Note: This is still a work in progress and is currently incomplete.
 +
 
 +
{| class="pretty3table"
 
|-
 
|-
 
| <center>'''Ref. Number'''</center>  
 
| <center>'''Ref. Number'''</center>  
Line 338: Line 473:
 
| <center>'''New Common Ref.'''</center>
 
| <center>'''New Common Ref.'''</center>
 
|-
 
|-
| A1  
+
| [[Top_10_2010-A1 | 2010-A1]]
 
| Injection  
 
| Injection  
 
|  
 
|  
'''&lt;check that all of these are mapped to ASVS identifiers, not TG&gt;'''
 
  
 
OWASP-0705
 
OWASP-0705
Line 360: Line 494:
  
 
|-
 
|-
| A2  
+
| [[Top_10_2010-A2 | 2010-A2]]
| Cross Site Scripting  
+
| Cross Site Scripting (XSS)
 
| OWASP-0701  
 
| OWASP-0701  
 
OWASP-0702  
 
OWASP-0702  
Line 370: Line 504:
  
 
|-
 
|-
| A3  
+
| [[Top_10_2010-A3 | 2010-A3]]
 
| Broken Authentication and Session Management  
 
| Broken Authentication and Session Management  
 
| OWASP-0300  
 
| OWASP-0300  
 
OWASP-0400  
 
OWASP-0400  
 
 
|-
 
|-
| A4  
+
| [[Top_10_2010-A4 | 2010-A4]]
 
| Insecure Direct Object References  
 
| Insecure Direct Object References  
 
| OWASP-0502
 
| OWASP-0502
 
|-
 
|-
| A5  
+
| [[Top_10_2010-A5 | 2010-A5]]
 
| Cross Site Request Forgery  
 
| Cross Site Request Forgery  
 
| OWASP-0405
 
| OWASP-0405
 
|-
 
|-
| A6  
+
| [[Top_10_2010-A6 | 2010-A6]]
 
| Security Misconfiguration  
 
| Security Misconfiguration  
 
| OWASP-0203  
 
| OWASP-0203  
 
OWASP-0204  
 
OWASP-0204  
 
 
|-
 
|-
| A7  
+
| [[Top_10_2010-A7 | 2010-A7]]
 
| Failure to Restrict URL Access  
 
| Failure to Restrict URL Access  
 
| OWASP-0500
 
| OWASP-0500
 
|-
 
|-
| A8  
+
| [[Top_10_2010-A8 | 2010-A8]]
 
| Unvalidated Redirects and Forwards  
 
| Unvalidated Redirects and Forwards  
 
| OWASP-0717
 
| OWASP-0717
 
|-
 
|-
| A9  
+
| [[Top_10_2010-A9 | 2010-A9]]
 
| Insecure Cryptographic Storage  
 
| Insecure Cryptographic Storage  
 
| OWASP-0209
 
| OWASP-0209
 
|-
 
|-
| A10  
+
| [[Top_10_2010-A10 | 2010-A10]]
 
| Insufficient Transport Layer Protection  
 
| Insufficient Transport Layer Protection  
 
| OWASP-0201
 
| OWASP-0201
 
|}
 
|}
  
== References  ==
+
End commented out section. }}}
 
 
*adding the (release) year into the numbering scheme can be problematic, because the document has a life cycle that goes over years ....
 
*One should rather try to accommodate a versioning scheme that is human readable in the reference number as well (e.g. V02, or RevA, or...)
 
 
 
----
 
 
 
*don't try to encode any information into the ID that is likely to change or be subject to debate. In the olden days of CVE, we used to have "CAN-1999-0067" which would change into "CVE-1999-0067" once the item was considered stable and sufficiently verified. That made the ID hard to use. Right now, OWASP-DV-001 encodes the term "data validation" in the DV acronym, but what happens if in a couple of years, some new and better term occurs, or the focus changes from validation to something else? (As an example, it's only recently that the "data validation" term itself has become popular.)
 
 
 
*carefully consider the range of values that your ID space supports, and if possible, allow it to expand. CVE has a "CVE-10K" problem because we never expected that we would ever come close to tracking 10,000 vulnerabilities a year. Red Hat had to change their advisory numbering scheme a couple years ago. etc.
 
 
 
*don't change the fundamental meaning of the ID once you've assigned it. This causes confusion, and more importantly, it immediately invalidates almost everyone's mappings to that ID - including people who you don't even know are using that ID.
 
 
 
*closely monitor the mappings that get made. Typos and misunderstandings are rarely caught. People may make assumptions about what "the item" really is, based only on a quick scan of a short name or title. Since you're dealing with diverse sources, there are likely to be many-to-many relationships in dealing with mappings.
 
 
 
*determine some kind of procedure for handling duplicates. They're gonna happen.
 
 
 
*the more you distribute the process of creating and assigning IDs between multiple people, the more inconsistencies and duplicates you will wind up with. This may be unavoidable, since the job is usually bigger than one person.
 
 
 
*determine some kind of procedure for deprecating IDs, i.e., "retiring" them and discouraging their use by others. This will probably happen for reasons other than duplicates. There should be some final record, somewhere, of what happened to the deprecated item - i.e., it shouldn't just disappear off the face of the earth.
 
 
 
----
 
 
 
Much of the discussion surrounding the establishment of "Common OWASP Numbering" can be found on the various [https://lists.owasp.org/mailman/listinfo OWASP mailing lists]. (For your convenience here is a direct link to the [https://lists.owasp.org/pipermail/owasp-testing/ OWASP Testing Guide Mailing List Archive].)
 
 
 
 
 
==== News ====
 
'''Coming soon!'''
 
 
 
==== Contributors ====
 
'''Project Leader'''
 
 
 
* Brad Causey
 
 
 
'''Project Contributors'''
 
 
 
* [http://www.owasp.org/index.php/User:Mike.boberski Mike Boberski] (ASVS)
 
* [[:User:Jeff Williams|Jeff Williams]] (ASVS)
 
* [[User:Wichers|Dave Wichers]] (ASVS)
 
* Andrew van der Stock (Development Guide)
 
* Eoin Keary (Code Review Guide)
 
* Matteo Meucci (Testing Guide)
 
* Leonardo Cavallari Militelli (ASDR)
 
  
'''Project Sponsorship'''
+
==== Project About ====
 +
{{:Projects/OWASP Common Numbering Project | Project About}}
  
[[Image:Bah-bw.JPG|175px]]
+
__NOTOC__ <headertabs />
  
__NOTOC__
 
<headertabs/>
 
  
 +
[[Category:OWASP_Document]]
 +
[[Category:OWASP_Alpha_Quality_Document]]
 +
[[Category:OWASP_Project|Common Numbering Project ]]
 
[[Category:OWASP_Application_Security_Verification_Standard_Project]] [[Category:How_To]]
 
[[Category:OWASP_Application_Security_Verification_Standard_Project]] [[Category:How_To]]

Latest revision as of 16:02, 17 April 2014



OWASP Inactive Banner.jpg

Home

Common OWASP Numbering

An exciting development, a new numbering scheme that will be common across various OWASP Guides and References is being developed. This numbering scheme is loosely based on the OWASP ASVS section and detailed requirements numbering. The OWASP ASVS, Guide, and Reference project leads and contributors plan to work together to develop a numbering scheme that facilitates easier mapping between various OWASP Guides and References, and that would allow for a period of transition as the Guides and References are updated to reflect the new numbering scheme. This project will provide a centralized clearinghouse for mapping information. For more information on this project, or if you wish to contribute, please contact Dave Wichers.

This common numbering scheme will be of requirements. A mapping of vulnerabilities to this requirements list will most likely be developed after the common requirements list is created. This common numbering scheme is intended to be independent of any particular OWASP project and is not intended to dictate how those projects are developed and organized. Its intent is to be a resource to facilitate cross referencing between related topics and to encourage, but not require, projects like the OWASP Guides to adopt a similar structure. But that decision is up to the respective project leads.

OWASP Common Requirements Numbering Scheme DRAFT

Proposed OWASP Common Requirements Numbering Scheme Format:
OCR-AUTHN-01
OCR-AUTHN-02
OCR-AUTHN-02.01
OCR-AUTHN-03
OCR-INPVAL-01
OCR-INPVAL-02 

Common Requirements Numbering Scheme Proposed Requirement Areas:

  • OCR-AUTHN: Authentication
  • OCR-SESS: Session Management
  • OCR-INPVAL: Input Validation
  • OCR-OUTENC: Output Encoding
  • OCR-AUTHZ: Functional and Data Layer Access Control
  • OCR-BUS: Business Logic
  • OCR-DATAP: Sensitive Data Protection
  • OCR-CRYPST: Cryptographic Storage
  • OCR-COMMS: Communication Security
  • OCR-ERROR: Error Handling
  • OCR-LOG: Logging
  • OCR-DBASE: Secure Database Usage
  • OCR-FILE: Secure File Access
  • OCR-MEM: Memory Management
  • OCR-GEN: General Coding Practices
  • OCR-CONFIG: Secure System Configuration
  • OCR-INTEG: Integrity
  • OCR-AVAIL: Availability
Reference
  • 1st Element - Document code (OCR=OWASP Common Requirements Number, ODG=OWASP Development Guide, OTG=OWASP Testing Guide, OCG=OWASP Code Review Guide, others reserved)
  • 2nd Element - Requirement Area (major)
  • 3rd Element - Detailed Requirement Identifier (minor with up to one sublevel (e.g., .01, .02)
  • 4th Element (Optional: DEPRECATED, or # for iterations, or legacy identifiers)

OWASP Common Requirements - DRAFT

The following is the first section we have developed of common requirements. It is the section on Authentication (OCR-AUTHN). This is draft, and your feedback is very welcome. Please provide any feedback to Dave Wichers.

OWASP Common Number
Common Requirement
Authentication Requirements
OCR-AUTH-01 All authentication controls operate on a trusted system (e.g., The server).
OCR-AUTH-02 Authentication is required for all pages and resources, except those specifically intended to be public.
OCR-AUTH-03 The application utilizes standardized, tested, and centralized authentication services.
OCR-AUTH-04 Authentication services utilize a centralized authentication store.
OCR-AUTH-05 All authentication controls fail securely.
OCR-AUTH-06 System configurable password strength requirements are enforced. This includes both minimum length and minimum complexity rules.
OCR-AUTH-07 Disallow account passwords to match any of the last N passwords for that account, where N is a system configurable value. This is done to discourage password re-use.
OCR-AUTH-08 Passwords must be a system configurable minimum age (e.g., one day old) before they can be changed, to prevent attacks on password re-use
OCR-AUTH-09 Password entry fields do not echo the user’s password when it is entered.
OCR-AUTH-10 Autocomplete is disabled for all password entry fields in HTML forms.
OCR-AUTH-11 Passwords are transmitted over an encrypted connection. Temporary passwords associated with email resets may be an exception to this rule.
OCR-AUTH-12 For authentication over HTTP, authentication credentials are transmitted only within the POST body and not in the URL.
OCR-AUTH-13 Authentication controls and application functionality minimize the leakage of user account names.
OCR-AUTH-14 Stored server side passwords are protected using cryptographically strong one-way salted hashes that use salts that are unique per account. (e.g., Do not use the MD5 or SHA-1 algorithms).
OCR-AUTH-15 Use large numbers of hash iterations or password based encryption to make it time consuming to calculate a single hashed password value.
OCR-AUTH-16 Stored passwords and cryptographic keys are readable and writeable only by the application.
OCR-AUTH-17 Brute force protection is provided after a system configurable number of invalid login attempts occur against an account within a configurable period of time (e.g., account is locked, CAPTCHA required, throttling enabled).
OCR-AUTH-18 Implement monitoring to identify attacks against multiple user accounts, utilizing the same password. This attack pattern is used to bypass standard lockouts, when valid user IDs can be harvested or inferred.
OCR-AUTH-19 The date/time of the last successful login is reported to the user after they login, along with the number of failed login attempts since the last successful login.
OCR-AUTH-20 Password changing mechanisms are at least as resistant to attack as the primary authentication mechanism.
OCR-AUTH-21 Passwords are required to be changed before they become older than a system configurable maximum age.
OCR-AUTH-22 Password reset questions support sufficiently random answers. (e.g., "favorite color" is a bad question because red, blue, green, are very common answers. Favorite book is another bad question that generates insufficiently random answers.).
OCR-AUTH-23 For email based resets, only send email to a pre-registered address with a temporary link/password. Reset questions should be asked after the user goes to the temporary page, not before the email is generated.
OCR-AUTH-24 Temporary passwords and links have a short, system configurable, expiration time.
OCR-AUTH-25 Users are required to change temporary passwords as soon as they are used.
OCR-AUTH-26 Users are notified when a password reset occurs on their account.
OCR-AUTH-27 Users must re-authenticate prior to performing security critical operations, such as change password, change email address, change mailing address, change mailing address, view very sensitive data, send funds, etc.
OCR-AUTH-28 All administrative and account management functions are at least as secure as the primary authentication mechanism.
OCR-AUTH-29 Authentication is required for services exposed to external systems that provide sensitive information or functions.
OCR-AUTH-30 All authentication credentials for accessing services external to the application are encrypted and stored in a protected location (e.g., not in source code).
OCR-AUTH-31 Multi-Factor Authentication is used for highly sensitive or high value systems or for specific high value transactions.



Project About

PROJECT INFO
What does this OWASP project offer you?
RELEASE(S) INFO
What releases are available for this project?
what is this project?
Name: OWASP Common Numbering Project (home page)
Purpose: An exciting development, a new numbering scheme that will be common across OWASP Guides and References is being developed. The numbering is loosely based on the OWASP ASVS section and detailed requirement numbering. OWASP ASVS, Guide, and Reference project leads and contributors as well as the OWASP leadership plan to work together to develop numbering that would allow for easy mapping between OWASP Guides and References, and that would allow for a period of transition as Guides and References are updated to reflect the new numbering. This project will provide a centralized clearinghouse for mapping information.
License: Creative Commons Attribution ShareAlike 3.0 license
who is working on this project?
Project Leader(s):
Project Contributor(s):
how can you learn more?
Project Pamphlet: Not Yet Created
Project Presentation:
Mailing list: Mailing List Archives
Project Roadmap: View
Key Contacts
current release
Not Yet Published
last reviewed release
Not Yet Reviewed


other releases