Fixed & duplicate findings

[esrabayramova]

Hello,

We are using a secret detection tool in our organization and the findings are submitted to defectdojo. However, detected secret does not block the pipeline.

1. If in the next commit (test in defectdojo context) the secret is not there anymore, is it possible to remove it from DefectDojo completely?
2. Another question is we want to remove duplicates in engagement-level rather than product-level, how would that be configured?
3. And finally, is it possible to upload the findings to the existing test (update it completely, removing previous findings) if the test name is already existent in engagement rather that creating tests with duplicate names? That would solve our first question.

Quick answer is appreciated.

Thanks in advance.

[kiblik]

For 1. and 3. I suppose you should use reimport/re-uploaded
UI (in test view):

API: /api/v2/reimport-scan/
It will not remove solved but close (mark as mitigated). Automatic removal is not implemented (and also not recommended - you want to have a history of findings for audit).

For 2.
UI (in engagement view):

[mtesauro]

I agree with @kiblik - reimport is what you want to use for the secrets scans you're asking about.

I'd also look at the API docs built into DefectDojo for the /reimport-scan endpoint especially the response's "delta" and "after" stanzas

[esrabayramova]

@kiblik @mtesauro Thank you for replies! Regarding the second question, does that mean that it should be done for each engagement manually? If I check deduplicate findings and delete duplicates in System Settings, will it be applied in a product level? Because I could not find within engagement or within products option as shown in the documentation. Also, for the first question, I understood that in UI it would have been done manually for each test as well, just to make sure, if I use /re-import API in upload script, will it be applied for all the uploads and no duplicate test names will be created?

[mtesauro]

Thank you for replies! Regarding the second question, does that mean that it should be done for each engagement manually?

Depends on if you're using the API or UI - for the UI, check this box during imports:

For the API, both the /import-scan & reimport-scan endpoints have this:

If I check deduplicate findings and delete duplicates in System Settings, will it be applied in a product level?

This turns on dedup generally/globally for DefectDojo - it needs to be enabled if your doing product or engagement level dedup

This set the max number of dedups that will be kept in DefectDojo - I usually don't use that unless I'm worried about storage space. The few times I've enabled it, I never set it lower than 5. DefectDojo seems to do better with a few dups around.

Because I could not find within engagement or within products option as shown in the documentation.

Log into the public demo then go to here: https://demo.defectdojo.org/product/1/new_engagement to see the checkbox I screenshot'ed above

Also, for the first question, I understood that in UI it would have been done manually for each test as well, just to make sure, if I use /re-import API in upload script, will it be applied for all the uploads and no duplicate test names will be created?

See my answer about about the checkbox and API boolean parameter.

HTH

[esrabayramova]

@mtesauro Thanks! We use script to upload the results via API, can we only use reimport-scan (not import-scan at all). Will it work fine if there is no previous test with the same name and the results are being uploaded for the first time?

[mtesauro]

@mtesauro Thanks! We use script to upload the results via API, can we only use reimport-scan (not import-scan at all). Will it work fine if there is no previous test with the same name and the results are being uploaded for the first time?

Yes, for the first/initial reimport, the delta will be all the findings since it's the only import - things like before and after also don't have great values for the first reimport e.g. before will be all zeros.

[esrabayramova]

Hello again, we are facing another issue. We changed import to reimport in script, the issue is when the findings are added, the previous ones are marked mitigated even though they are the same issues. For example, if there were 4 findings and in reimport they still remain, it will mark previously added 4 to mitigated and add another 4 - so mitigated 4 and active 4 findings will be shown. I marked delete duplicates in system settings - but it does not seem to work. Here is the screenshot:

[mtesauro]

Some things to note about reimport:

1. Make sure that the scope aka what you test does NOT change from scan to scan e.g. for your secret scanner, restrict the scanner to the same repo when reimporting
2. reimport is designed to take a 'diff' of each added scan so the overall findings of the test are the net difference between the new and previous scan. So, using your example:

• reimport 1: 4 findings added - net result = 4 active findings
• reimport 2: same 4 findings - net results = 4 active findings, 4 marked inactive/mitigated

So it appears from your description above that reimport is doing the right thing, For example, if you scan the same network segment with Nessus ever week and reimport those scans, you'd expect:

• Week 1: 4 findings - net result = 4 active findings
• Week 2: 3 findings are the same as week 1 - net results = 3 active findings with 1 marked as mitigated
• Week 3: 5 findings, 4 are the same as week 1 & 1 is brand new - net results = 5 active findings (with 1 re-activated that was mitigated in week 2 & 1 new finding)

[esrabayramova]

reimport 2: same 4 findings - net results = 4 active findings, 4 marked inactive/mitigated - is it possible to do it in a way that if the findings are the same as the previous ones/if they are not mitigated, they just remain as they were (active) and the duplicates do not get added/ previous ones do not get marked "mitigated" ?

[mtesauro]

The idea behind reimport is to do a continually diff of recurring scans so that those that are active in that test are the only ones you need to worry about. The rest will be activated or mitigated based on if they reappear or disappear from future scan runs.

[esrabayramova]

I understand that the idea behind the reimport is to do a diff of recurring scans however, if the findings are the same as the previous findings, it means that there is no difference, so marking the previously added ones as mitigated and adding the exact same findings creates redundancy and complicates auditing process (monitoring really mitigated findings). If there is no any workaround, is there any other way to achieve what we want? Thanks for your time,

[valentijnscholten]

reimport 2: same 4 findings - net results = 4 active findings, 4 marked inactive/mitigated - is it possible to do it in a way that if the findings are the same as the previous ones/if they are not mitigated, they just remain as they were (active) and the duplicates do not get added/ previous ones do not get marked "mitigated" ?

If the report contains the exact same 4 findings, the net result will be that you have 4 active findings.

Unless you run into reports where there is not enough information in the reports to detect identical existing findings: #3958