Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Question] How defectDojoCloseOldFindings works? #87

Open
lbi22 opened this issue Nov 26, 2024 · 4 comments
Open

[Question] How defectDojoCloseOldFindings works? #87

lbi22 opened this issue Nov 26, 2024 · 4 comments
Labels
question Further information is requested

Comments

@lbi22
Copy link
Contributor

lbi22 commented Nov 26, 2024

Question

Hello,

I'm trying to refine and understand my Trivy/DefectDojpo configuration. I would like to understand a bit better how the defectDojoCloseOldFindings and defectDojoCloseOldFindingsProductScope works because I did not understand them very well. More specifically, I would like to understand the "logic" behind that and how the tool will decide what is closed and what is not.
If you can help me with that, it would be much appreciated!
Cheers

@lbi22 lbi22 added the question Further information is requested label Nov 26, 2024
@rndmh3ro
Copy link
Collaborator

We merely duplicate the API from defectdojo here, so the logix is entirely on DD's side.

So, from the docs:

  • close_old_findings : if true, findings that are not
    duplicates and that were in the previous scan of the same type
    (example ZAP) for the same engagement (or product in case of
    "close_old_findings_product_scope") and that are not present in the new
    scan are closed (Inactive, Verified, Mitigated).
  • close_old_findings_product_scope : if true, close_old_findings applies
    to all findings of the same type in the product. Note that
    "Deduplication on engagement" is no longer used to determine the
    scope of close_old_findings.

and implementation:

# Close Old Findings has changed. The default is engagement only, and it requires a second flag to expand to the product scope.
# Exposing the choice as two different check boxes.
# If 'close_old_findings_product_scope' is selected, the backend will ensure that both flags are set.
close_old_findings = forms.BooleanField(help_text="Old findings no longer present in the new report get closed as mitigated when importing. "
                                                    "If service has been set, only the findings for this service will be closed. "
                                                    "This only affects findings within the same engagement.",
                                        label="Close old findings within this engagement",
                                        required=False,
                                        initial=False)
close_old_findings_product_scope = forms.BooleanField(help_text="Old findings no longer present in the new report get closed as mitigated when importing. "
                                                    "If service has been set, only the findings for this service will be closed. "
                                                    "This only affects findings within the same product.",
                                        label="Close old findings within this product",
                                        required=False,
                                        initial=False)

@lbi22
Copy link
Contributor Author

lbi22 commented Nov 28, 2024

Hey @rndmh3ro, thank you very much for the response. It helped me understand better what's behind it.
I still have difficulties understanding how to set up the correct value from this repo to close only the findings that are no longer present. What I did for the moment was change the Product Name to the cluster name (so I can distinguish from which cluster the finding is coming from), but when I turn on "close_old_findings", it closes many findings that should not be closed.
Do you have any recommendations on any particular value that I should set up to make it work as expected?
Thank you again for your time

@lbi22
Copy link
Contributor Author

lbi22 commented Nov 29, 2024

I have another question on the same subject if it's not too much to ask. Is there a possibility of changing the status of an existing finding if the report is removed from the cluster? Or is it the case already?

@tidusete
Copy link

tidusete commented Dec 2, 2024

@lbi22 be careful with the close_old_findings & close_old_findings_product_scope. Maybe you are having the problem that was defined here. One important part of the deduplication and re-import scans is to ensure that the fields that are compared between findings are the same.

On trivy-operator-scans are this ones https://github.com/DefectDojo/django-DefectDojo/blob/master/dojo/settings/settings.dist.py#L1236 and you can always modify them. But this issue is more defectdojo rather than trivy-dojo-report-operator

Tip: Use the defectdojo API, compare the findings and check for the field called hash_code if both are the same you will have a deduplication. Not sure on the re-import scan now. But i guess is the same.
One problem that maybe you can have is the description because is linked to replicaset so what you can do is define on your defectdojo the following value:
DD_HASHCODE_FIELDS_PER_SCANNER: '{"Trivy Operator Scan":["vulnerability_ids","component_name","severity"]}'
To relay on vulnerability_ids","component_name","severity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants