[Owasp_defectdojo_project] DefectDojo De-duplication of Findings

Charles Neill cneill09 at gmail.com
Fri Jul 29 21:46:00 UTC 2016

Agreed with Jay about VettedFindings, I don't think fragmenting the Finding
model is the way to go.

My thoughts on Jay's question about dupe detection:

Mitigated Findings that are re-discovered by subsequent testing should be
re-opened if Finding names and Endpoints match, and added as new findings
if either doesn't match. This allows any context (e.g. In test notes,
emails, etc) that surrounded the original finding to be preserved, while
not making any assumptions about systems that may or may not be related. It
might be useful to add a "regression" field to Finding to better track its
status. Could be boolean (current status = regression) or an Int (current
number of regressions on this Finding = #)


On Fri, Jul 29, 2016, 16:02 Jay Paz <jay.paz at gmail.com> wrote:

> I think it is a worthy addition, but don't believe you need an additional '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
> all_findings = Finding.objects.filter(test__engagement__product=product)
> From there you can compare the incoming findings to the existing ones and
> weed out the dupes.  My questions are:
> 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.
> 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.
> 3.  What if the severity is different, or the environment, etc...
> 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.
> my two cents,
> Jay
> On Fri, Jul 29, 2016 at 3:52 PM, Greg Anderson <greg.anderson at owasp.org>
> wrote:
>> Hi Everyone!
>> *My Question:*
>> Should this be in core?
>> I think so, but I'm also not sure I could reasonably do this as a plugin
>> because it touches so many things:
>> *Okay the details:*
>> 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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.owasp.org/pipermail/owasp_defectdojo_project/attachments/20160729/b1b4f71e/attachment.html>

More information about the Owasp_defectdojo_project mailing list