<div dir="ltr">At the Test level we also wanted to preserve what the scanner has found, rather than throw out findings.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 29, 2016 at 4:15 PM, Greg Anderson <span dir="ltr"><<a href="mailto:greg.anderson@owasp.org" target="_blank">greg.anderson@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="ltr">Hi Jay,<div><br></div><div>Great points.</div><div><br></div><div>1. <span style="font-size:12.8px"> </span><span style="font-size:12.8px">What do you do if the existing finding is already mitigated or inactive - does it get reactivated because an incoming finding matches it, or does a new finding get created instead.</span></div><div><br></div><div>My thought would be to compare the dates. If at a later time a duplicate finding was added as 'active' then I believe it should take on the status of the latest round of tests.</div><div><br></div><div>2.<span style="font-size:12.8px">  How will you compare them and decide they are dupes?  What if the incoming finding is for a different endpoint, will the endpoint be added to the existing finding or a new finding created with its own list of endpoints.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">How TF de-duplicates is it compares the, url, parameter, and CWE. For Dojo, my initial thought was to compare endpoints and titles, although we could instead look at / include CWE. Though often Dojo findings don't have CWEs.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">3. </span><span style="font-size:12.8px">What if the severity is different, or the environment, etc...</span></div><div><br></div><div>Per 2, a different environment would be a different finding since the endpoint would be different. For severity, I would refer to the most recent like 1.</div><div><br></div><div><br></div><div>My thoughts on why it should be a separate model was for filtering. For metrics I thought it would be easier to aggregate. Otherwise how would you tell them apart for the Product or Product Type metrics? What do you think of the idea of instead adding a 'vetted' field to the finding model instead? </div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Fri, Jul 29, 2016 at 4:07 PM,  <span dir="ltr"><<a href="mailto:owasp_defectdojo_project-owner@lists.owasp.org" target="_blank">owasp_defectdojo_project-owner@lists.owasp.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">As list administrator, your authorization is requested for the<br>
following mailing list posting:<br>
<br>
    List:    <a href="mailto:Owasp_defectdojo_project@lists.owasp.org" target="_blank">Owasp_defectdojo_project@lists.owasp.org</a><br>
    From:    <a href="mailto:jay.paz@gmail.com" target="_blank">jay.paz@gmail.com</a><br>
    Subject: Re: DefectDojo De-duplication of Findings<br>
    Reason:  Post by non-member to a members-only list<br>
<br>
At your convenience, visit:<br>
<br>
    <a href="https://lists.owasp.org/mailman/admindb/owasp_defectdojo_project" rel="noreferrer" target="_blank">https://lists.owasp.org/mailman/admindb/owasp_defectdojo_project</a><br>
<br>
to approve or deny the request.<br>
<br><br></div></div><span class="">---------- Forwarded message ----------<br>From: Jay Paz <<a href="mailto:jay.paz@gmail.com" target="_blank">jay.paz@gmail.com</a>><br>To: Greg Anderson <<a href="mailto:greg.anderson@owasp.org" target="_blank">greg.anderson@owasp.org</a>><br>Cc: <a href="mailto:owasp_defectdojo_project@lists.owasp.org" target="_blank">owasp_defectdojo_project@lists.owasp.org</a>, <a href="mailto:cneill09@gmail.com" target="_blank">cneill09@gmail.com</a>, Matt Tesauro <<a href="mailto:mtesauro@gmail.com" target="_blank">mtesauro@gmail.com</a>><br>Date: Fri, 29 Jul 2016 16:02:37 -0500<br>Subject: Re: DefectDojo De-duplication of Findings<br></span><div dir="ltr">I think it is a worthy addition, but don't believe you need an additional '<span style="font-size:12.8px">VettedFindings' model.  Te Engagement already holds a list of all its findings and it is easy to query them because of the reverse look up capabilities of Django.  To find all findings associated with a Product all you have to do is query for them </span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">all_findings = Finding.objects.filter(test__engagement__product=product)</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">From there you can compare the incoming findings to the existing ones and weed out the dupes.  My questions are:</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">1.  What do you do if the existing finding is already mitigated or inactive - does it get reactivated because an incoming finding matches it, or does a new finding get created instead.</span></div><div><span style="font-size:12.8px">2.  How will you compare them and decide they are dupes?  What if the incoming finding is for a different endpoint, will the endpoint be added to the existing finding or a new finding created with its own list of endpoints.</span></div><div><span style="font-size:12.8px">3.  What if the severity is different, or the environment, etc...</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I think adding a new model complicates the process and is not necessary.  By using Django's reverse querying capabilities you can handle this without affecting anything else that depends on the Finding model.  Because of the search capabilities, Findings are already indexed really well, and I don't believe you will have a performance issue.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">my two cents,</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Jay</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 29, 2016 at 3:52 PM, Greg Anderson <span dir="ltr"><<a href="mailto:greg.anderson@owasp.org" target="_blank">greg.anderson@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="ltr">Hi Everyone!<div><br></div><div><b>My Question:</b></div><div>Should this be in core?</div><div><br></div><div>I think so, but I'm also not sure I could reasonably do this as a plugin because it touches so many things:</div><div><br></div><div><b>Okay the details:</b></div><div><div><br></div><div>A big item that Pearson needs for Dojo is de-duplication of findings. This is something that ThreadFix does that dojo does not. The idea is that you can upload multiple scans and Dojo will automatically try to remove duplicates. How I was thinking of implementing this was adding a ManytoMany relationship to Engagements with a new model called VettedFindings. The engagement would hold a list of findings that would be compared when new ones are added. If a match doesn't exist it would be added to the list rather than being filtered on the fly. I think this would be best for performance. However, it has far reaching impact on the metrics, e.g. all findings filters would have to be replaced with vettedfinding filters (although they would be identical).</div><div><br></div><div><br></div></div></div>
</blockquote></div><br></div>
<br><br>---------- Forwarded message ----------<br>From: <a href="mailto:owasp_defectdojo_project-request@lists.owasp.org" target="_blank">owasp_defectdojo_project-request@lists.owasp.org</a><br>To: <br>Cc: <br>Date: Fri, 29 Jul 2016 21:07:13 +0000<br>Subject: confirm 28a5fe55861e8974ab290acb4a2db9c52bb7891e<br>If you reply to this message, keeping the Subject: header intact,<br>
Mailman will discard the held message.  Do this if the message is<br>
spam.  If you reply to this message and include an Approved: header<br>
with the list password in it, the message will be approved for posting<br>
to the list.  The Approved: header can also appear in the first line<br>
of the body of the reply.<br></blockquote></div><br></div>
</blockquote></div><br></div>