-
Notifications
You must be signed in to change notification settings - Fork 1.7k
[docs] Add deduplication hashcode fields to parser descriptions #12648
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
base: bugfix
Are you sure you want to change the base?
Conversation
No security concerns detected in this pull request. All finding details can be found in the DryRun Security Dashboard. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved
@@ -41,3 +41,12 @@ All properties are strings and are required by the parser. As the parser evolved | |||
|
|||
### Sample Scan Data | |||
Sample Anchore-Engine scans can be found [here](https://github.com/DefectDojo/django-DefectDojo/tree/master/unittests/scans/anchore_engine) | |||
|
|||
### Default Deduplication Hashcode Fields | |||
By default, DefectDojo identifies duplicate Findings using these hashcode fields: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By default, DefectDojo identifies duplicate Findings using these hashcode fields: | |
By default, DefectDojo identifies duplicate Findings using these [hashcode fields](<url to docs>): |
I was wondering if it would be helpful to have a link to the deduplication/hashcode docs here? Not sure if it's documented or that it should point to settings.dist.py for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like that idea @valentijnscholten but I'm a bit concerned that as the settings.dist.py changes the links to the line number for that hashcode could change and 'break' those links - or at least point them to the something else.
That could be a maintenance burden. 🤷
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could be a good link to use: https://docs.defectdojo.com/en/open_source/archived_docs/usage/features/#deduplication-configuration (until it's moved out of _archive which I think we should do)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @valentijnscholten - I can leave this PR in drafts and prioritize consolidating all of the deduplication docs. And then when I'm done that I can add a link. Right now there are a few different pages for deduplication between Pro, OS etc..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The longer this PR stays open, the more conflicts it will get. I think it could work to just add the link I mentioned above and get it merged. When the docs are updated/renamed/moved, you/we only have to update the link via search/replace.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @valentijnscholten ☝️ that we can merge this with the link and have a follow-on PR to address the rest.
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
Conflicts have been resolved. A maintainer will review the pull request shortly. |
This adds information on default hashcode values to the file parser documentation.
If specific deduplication hashcodes are listed for a given scan type in settings.dist.py, they are added to docs. If not, the default hash code values:
are used instead.
These file changes were done programmatically but manually reviewed to ensure accuracy, so if a change to the format requested I'll make sure it applies to all files governed by this PR.