<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Point taken. And a better solution Simon. But at least a little bit of governance here would be nice.<br><br>Eoin Keary<div>OWASP Volunteer</div><div>@eoinkeary</div><div><span style="font-size: 13pt;"><br></span></div><div><br></div></div><div><br>On 1 Dec 2015, at 9:19 a.m., psiinon <<a href="mailto:psiinon@gmail.com">psiinon@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div><div><div><div>I actually disagree.<br></div>I'm fine with vendors leading most types of projects - we should be encouraging more vendor involvement / sponsorship.<br></div>But I now dont think its a good idea for any vendor to lead a project which is designed to evaluate competing commercial and open source projects.<br><br></div>Cheers,<br><br></div>Simon<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 30, 2015 at 11:17 AM, Eoin Keary <span dir="ltr"><<a href="mailto:eoin.keary@owasp.org" target="_blank">eoin.keary@owasp.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>I don't believe vendors should lead any project. </div><div><br></div><div>Contribute? yes, Lead? No.</div><div><br></div><div>This goes for all projects and shall help with independence and objectivity. </div><span class="HOEnZb"><font color="#888888"><div><br></div><div><br>Eoin Keary<div>OWASP Volunteer</div><div>@eoinkeary</div><div><span style="font-size:13pt"><br></span></div><div><br></div></div></font></span><div><div class="h5"><div><br>On 28 Nov 2015, at 11:39 p.m., Kevin W. Wall <<a href="mailto:kevin.w.wall@gmail.com" target="_blank">kevin.w.wall@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><span>Until very recently, I've been following at a distance this dispute between</span><br><span>various OWASP members and Contrast Security over the latter's advertising</span><br><span>references to the OWASP Benchmark Project</span><br><span></span><br><span>While I too believe that mistakes were made, I believe that we all need to</span><br><span>take a step back and not throw out the baby with the bath water.</span><br><span></span><br><span>While unlike Johanna, I have not executed the OWASP Benchmark Project for</span><br><span>any given SAST or DAST tool, having used many such commercial tools, I feel</span><br><span>qualified to render a reasoned opinion of the OWASP Benchmark Project, and</span><br><span>perhaps some steps that we can take towards amicable resolution.</span><br><span></span><br><span>Let me start with the OWASP Benchmark Project. I find the idea of having an</span><br><span>extensive baseline of tests against we can gauge the effectiveness of SAST</span><br><span>and DAST software quite sound. In a way, these tests are analogous to unit</span><br><span>tests that we, as developers, use to find bugs in our code and help us</span><br><span>improve it, where here the discovered false positives and false negatives</span><br><span>being revealed are being used as the PASS / FAIL criteria for the tests. Just</span><br><span>as in unit testing, where the ideal is to have extensive tests to broaden one's</span><br><span>"test coverage" of the software under test, the Benchmark Project strives</span><br><span>to have a broad set of tests to assist in revealing deficiencies (with</span><br><span>the goal of removing these "defects") in various SAST and DAST tools.</span><br><span></span><br><span>This is all well and good, and I whole-heartedly applaud this effort.</span><br><span></span><br><span>However, I see several ways that this Benchmark Project fails. For one,</span><br><span>we have no way to measure the "test coverage" of the vulnerabilities that</span><br><span>the Benchmark Project claims to measure. There are (by figures that I've</span><br><span>seen claimed) something like 21,000 different test cases. How do we, as AppSec</span><br><span>people, know if these 21k 'tests' provide "even" test coverage? For</span><br><span>instance, it is not unreasonable to think that they may be heavy coverage</span><br><span>on tests that are easy to create (e.g., SQLi, buffer overflows, XSS) and</span><br><span>a much lesser emphasis on "test cases" for things like cryptographic</span><br><span>weaknesses. (This would not be surprising in the least, since the coverage</span><br><span>of every SAST and DAST tool that I've ever used seems to excel in some</span><br><span>areas and absolutely suck in others.)</span><br><span></span><br><span>Another way that the Benchmark Project is lacking is one that is admitted</span><br><span>on the Benchmark Project wiki page under the "Benchmark Validity" section:</span><br><span>    The Benchmark tests are not exactly like real applications. The</span><br><span>    tests are derived from coding patterns observed in real</span><br><span>    applications, but the majority of them are considerably *simpler*</span><br><span>    than real applications. That is, most real world applications will</span><br><span>    be considerably harder to successfully analyse than the OWASP</span><br><span>    Benchmark Test Suite. Although the tests are based on real code,</span><br><span>    it is possible that some tests may have coding patterns that don't</span><br><span>    occur frequently in real code.</span><br><span></span><br><span>A lot of tools are great at detecting data and control flows that are simple,</span><br><span>but fail completely when facing "real code" that uses complex MVC frameworks</span><br><span>like Spring Framework or Apache Struts. The bottom line is that we need</span><br><span>realistic tests. While we can be fairly certain that if a SAST or DAST tool</span><br><span>misses the low bar of one of the existing Benchmark Project test cases, if</span><br><span>they are able to _pass_ those tests, it still says *absolutely nothing* about</span><br><span>their ability to detect vulnerabilities in real world code where the code</span><br><span>is often orders of magnitude more complex. (And I would argue that this is</span><br><span>one reason we see the false positive rate so high for SAST and DAST tools;</span><br><span>rather than err on the side of false negatives, they flag "issues" that</span><br><span>they are generally unreliable and then rely on appsec analysts to discern which</span><br><span>are real and which are red herrings. This is still easier than if they</span><br><span>appsec engineers had to hunt down these potential issues manually and then</span><br><span>analyze them, so it is not entirely inappropriate. As long as the tool</span><br><span>provides some sort of "confidence" indicator for the various issues that it</span><br><span>finds, an analyst can easily decide whether they are worth spending effort on</span><br><span>further investigation.)</span><br><span></span><br><span>This brings me to what I see as the third major area of where the Benchmark</span><br><span>Project is lacking. In striving to be simple, it attempts to distill all the</span><br><span>findings into a single metric. The nicest thing I can think of saying about</span><br><span>this is that it is woefully naive and misguided. I think where it is misguided</span><br><span>is that it assumes that every IT organization in every company weights</span><br><span>everything equally. For instance, false positives and false negatives are both</span><br><span>_equally_ bad. However, in reality, most organizations that I've been involved</span><br><span>in AppSec would highly prefer false positives over false negatives. Likewise,</span><br><span>all categories (e.g., buffer overflows, heap corruption, SQLi, XSS, CSRF,</span><br><span>etc.) are all weighted equally. Every appsec engineer knows that this is</span><br><span>generally unrealistic; indeed it is _one_ reason that we have different risk</span><br><span>ratings for different findings. Also, if a company writes all of their</span><br><span>applications in "safe" programming languages like C# or Java, then categories</span><br><span>like buffer overflows or heap corruption completely disappear. What that means</span><br><span>is that those companies don't care at all whether or not a given SAST or DAST</span><br><span>tool can find those categories of vulnerabilities or not because they are</span><br><span>completely irrelevant for them. However, because there is no way to customize</span><br><span>the weighting of Benchmark Project findings when run for a given tool,</span><br><span>everything is attempted to be shoe-horned into a single magical figure. The</span><br><span>result is that that magical Benchmark Project figure becomes almost</span><br><span>meaningless. At best, it's meaning is very subjective and not at all as</span><br><span>objective as Contrast's advertising is attempting to lead people to believe.</span><br><span></span><br><span>I believe that the general reaction to all of this has been negative, at</span><br><span>least based on the comments that I've read not only in the OWASP mailing</span><br><span>lists, but also on Twitter. In the end, this will be damaging to either</span><br><span>OWASP's overall reputation or at the very least, the reputation of the</span><br><span>OWASP Benchmark Project, both of which I think most of us agreed is</span><br><span>bad for the appsec community in general.</span><br><span></span><br><span>Therefore, I have a simple proposal towards resolution. I would appeal to</span><br><span>the OWASP project leaders to appeal to the OWASP Board to simply mark the</span><br><span>OWASP Benchmark Project Wiki page (and ideally, its GitHub site) as noting</span><br><span>that the findings are being disputed. For the wiki page, we could do this</span><br><span>in a manner that Wikipedia marks disputes, using a Template:Disputed tag</span><br><span>(see <a href="https://en.wikipedia.org/wiki/Template:Disputed_tag" target="_blank">https://en.wikipedia.org/wiki/Template:Disputed_tag</a>) or their</span><br><span>"Accurracy Disputes" (for example, see</span><br><span><a href="https://en.wikipedia.org/wiki/Wikipedia:Accuracy_dispute" target="_blank">https://en.wikipedia.org/wiki/Wikipedia:Accuracy_dispute</a></span><br><span>and <a href="https://en.wikipedia.org/wiki/Category:Accuracy_disputes" target="_blank">https://en.wikipedia.org/wiki/Category:Accuracy_disputes</a>)</span><br><span></span><br><span>At a mininum, we should have this tag result in rendering something like:</span><br><span>    "The use and accuracy of this page is currently being disputed.</span><br><span>    OWASP does not support any vendor endorsing any of their</span><br><span>    software according to the scores resulting in execution of</span><br><span>    the OWASP Benchmark."</span><br><span>that the OWASP Board should apply (so that no one is permitted to</span><br><span>remove it without proper authorization).</span><br><span></span><br><span>I will leave the exact wording up to the board. But just like disputed</span><br><span>pages on Wikipedia, OWASP must take action on this or I think they are</span><br><span>likely to have credibility issues in the future.</span><br><span></span><br><span>Thank you for listening,</span><br><span>-kevin wall</span><br><span>-- </span><br><span>Blog: <a href="http://off-the-wall-security.blogspot.com/" target="_blank">http://off-the-wall-security.blogspot.com/</a></span><br><span>NSA: All your crypto bit are belong to us.</span><br><span>_______________________________________________</span><br><span>Owasp-board mailing list</span><br><span><a href="mailto:Owasp-board@lists.owasp.org" target="_blank">Owasp-board@lists.owasp.org</a></span><br><span><a href="https://lists.owasp.org/mailman/listinfo/owasp-board" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-board</a></span><br></div></blockquote></div></div></div><br>_______________________________________________<br>
Owasp-board mailing list<br>
<a href="mailto:Owasp-board@lists.owasp.org">Owasp-board@lists.owasp.org</a><br>
<a href="https://lists.owasp.org/mailman/listinfo/owasp-board" rel="noreferrer" target="_blank">https://lists.owasp.org/mailman/listinfo/owasp-board</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><a href="https://www.owasp.org/index.php/ZAP" target="_blank">OWASP ZAP</a> Project leader<br></div>
</div>
</div></blockquote></body></html>