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"
Deleted user (talk | contribs) |
Deleted user (talk | contribs) |
||
| Line 1: | Line 1: | ||
| + | == Latest Proposal == | ||
| + | |||
Here is the latest proposal for your consideration: | Here is the latest proposal for your consideration: | ||
| Line 21: | Line 23: | ||
[[Category:OWASP Application Security Verification Standard Project]] | [[Category:OWASP Application Security Verification Standard Project]] | ||
[[Category:How To]] | [[Category:How To]] | ||
| + | |||
| + | |||
| + | == Notes and Guidance == | ||
| + | |||
| + | A handful of suggestions: | ||
| + | |||
| + | - 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. | ||
Revision as of 19:04, 7 January 2010
Latest Proposal
Here is the latest proposal for your consideration:
ASVS Ref. Number OWASP-V0604
TG Ref. Number OWASP-T0604-DV-005 (compared to currently: OWASP-DV-005)
CRG Ref. Number OWASP-C0604-DV-005
Guide Ref. Number OWASP-D0604 (goes into guidance at this level, in the next release)
Where,
OWASP-V0604 == V6.4 Verify that all untrusted data that is output to SQL interpreters use parameterized interfaces, prepared statements, or are escaped properly.
Notes and Guidance
A handful of suggestions:
- 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.
