Right, the next step if there were agreement would be to basically take the table from the TG that summarizes the IDs, add a couple columns, and start mapping.<br><br>Then, each doc would be updated in turn, and yes each would then have to address any holes. Not an issue from the ASVS or dev guide perspective.<br>

<br clear="all">Mike<br>
<br><br><div class="gmail_quote">On Wed, Jan 6, 2010 at 5:09 PM, Brad Causey <span dir="ltr">&lt;<a href="mailto:bradcausey@gmail.com">bradcausey@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

Thinking from the perspective of a purely ignorant person, this is<br>
rather confusing. Problem is, it totally makes sense as to why you did<br>
what you did, to me. So which of those numbers would be final one? And<br>
with that number alone, could I find what I needed in each guide?<br>
<br>
*thinking aloud*<br>
Ideally, we have 2 ultimate goals in my mind. (bear with me here)<br>
1. create a central ID number, and provide a mapping to each project.<br>
(maybe a good interim goal)<br>
2. Actually _change_ each OWASP guide to match the TG or some agreed<br>
upon numbering system.<br>
<br>
Now, you are probably all asking &quot;why are we chosing to go with the<br>
TG?&quot;. Well I wasn&#39;t sold either, and I&#39;m still not 100%. But it does<br>
appear to provide detailed numberin for specific vulnerabilities, and<br>
has a pretty good following. (and I&#39;m partial because I currently rely<br>
on it)<br>
Here is the catch! There are going to be holes no matter which<br>
direction we take, for example, the TG has items the ASVS doesn&#39;t.<br>
Which is why I&#39;m voting for a super detailed comprehensive &quot;master<br>
list&quot; and match them up for now, item #1. And allow each project to<br>
catch up to the list, ultimately leading to a truly complete #2.<br>
<br>
I&#39;m literally thinking out loud here guys, so fire back full force.<br>
*/thinking aloud*<br>
<br>
<br>
-Brad Causey<br>
CISSP, MCSE, C|EH, CIFI, CGSP<br>
<br>
<a href="http://www.owasp.org" target="_blank">http://www.owasp.org</a><br>
--<br>
Never underestimate the time, expense, and effort an opponent will<br>
expend to break a code. (Robert Morris)<br>
--<br>
<br>
<br>
<br>
On Wed, Jan 6, 2010 at 1:44 PM, Boberski, Michael [USA]<br>
&lt;<a href="mailto:boberski_michael@bah.com">boberski_michael@bah.com</a>&gt; wrote:<br>
&gt; Let us work on this using a specific example, SQL Injection:<br>
&gt;<br>
&gt; Here is a proposal for your consideration:<br>
&gt;<br>
&gt; ASVS Ref. Number<br>
&gt; OWASP-V0604<br>
&gt;<br>
&gt; TG Ref. Number<br>
&gt; OWASP-T0604-DV-005<br>
&gt; (compared to currently: OWASP-DV-005)<br>
&gt;<br>
&gt; CRG Ref. Number<br>
&gt; OWASP-C0604-DV-005<br>
&gt;<br>
&gt; Guide Ref. Number<br>
&gt; OWASP-D0604<br>
&gt; (goes into guidance at this level, in the next release)<br>
&gt;<br>
&gt; Where,<br>
&gt;<br>
&gt; OWASP-V0604 == V6.4  Verify that all untrusted data that is output to SQL interpreters use parameterized interfaces, prepared statements, or are escaped properly.<br>
&gt;<br>
&gt; Mike B.<br>
&gt; _______________________________________________<br>
&gt; Owasp-topten mailing list<br>
&gt; <a href="mailto:Owasp-topten@lists.owasp.org">Owasp-topten@lists.owasp.org</a><br>
&gt; <a href="https://lists.owasp.org/mailman/listinfo/owasp-topten" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-topten</a><br>
&gt;<br>
_______________________________________________<br>
Owasp-testing mailing list<br>
<a href="mailto:Owasp-testing@lists.owasp.org">Owasp-testing@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/owasp-testing" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-testing</a><br>
</blockquote></div><br>