Closed zakrush closed 2 years ago
@zakrush your report have 2 vulnerabilities but they have most of there attributes with the same value (title, severity, file, etc) So the default hash algorithm see them equals.
@damiencarol thank you. I miss this, I'm so sorry. Close this issue.
@damiencarol sorry again. https://github.com/DefectDojo/django-DefectDojo/blob/e77427d401c7bf9d29b056e76d902638a8416c5c/dojo/tools/gitlab_sast/parser.py#L63 Maybe modify this? Becouse into my case we are losing some finding, that incorrect as I think. Maybe are using list for items?
@zakrush you should take a look at our de-duplication algorithm documentation
@damiencarol I see this. I setup unique_id_from_tools for it.
In this case, when vulnerabilities is parsing, the first vulns is overrided the second vuln with the same ID. Code is here: https://github.com/DefectDojo/django-DefectDojo/blob/e77427d401c7bf9d29b056e76d902638a8416c5c/dojo/tools/gitlab_sast/parser.py#L60-L64
In this case I think DD is should parse my example as 2 findings, and dedup it as describe to settings.dist.py. (in'my case i should get 2 findings. One of them is duplicated marked)
Looks like the id
field in the Gitlab report isn't actually unique, so we cannot use it as a key in our dictionary in the parser.
@damiencarol Yes. Is it. It's bug of semgrep. I create issue for this tool. https://github.com/returntocorp/semgrep-action/issues/488
@zakrush any news on this one? Have you been able to confirm that it's the tool that produce wrong data in the report?
Yes. It's tool are given incorect data. Semgrep-agent is hashed data defined only by namespace and path, that incorrect for SAST tools
Is it id.
str(uuid.uuid5(uuid.NAMESPACE_URL, str(self.path))),
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Be informative GItLab SAST that containt 2 vulnerability parsing as one vuln.
Bug description Incorrect nums of Findings for Gitlab SAST report
Steps to reproduce Steps to reproduce the behavior:
Expected behavior 2 different findings was created.
Deployment method (select with an
X
)X
] Docker ComposeEnvironment information
Logs Use
docker-compose logs
here no errorsAttach debug logs:
Sample scan files GL-new_sql.txt
Screenshots I have only this finding:
Additional context (optional) Add any other context about the problem here.