OpenVAS/Greenbone: XML vs CSV import and re-import create inconsistent findings, inflate counts & missing information

[Hamudah]

Bug description

When we import the same Greenbone / OpenVAS scan into DefectDojo we get inconsistent results and not all information is transferred from the scan results:

• XML vs CSV – importing the identical report in XML format vs CSV produces a different set / count of findings.
• Re-import of the exact same file – clicking Re-import on an unchanged scan again changes the finding list: some previously-created findings are closed, new ones are created, and several remain “untouched.” The net effect is an ever-growing total count without any real changes in the source data (see attached screenshot).

Question: Is this a known issue with the OpenVAS parser or the deduplication logic?

Steps to reproduce

1. In DefectDojo, create a Test and Import Scan → Greenbone / OpenVAS → upload scan.xml.
2. Note the IDs and total number of findings created.
3. In the same Test, Import Scan again but upload the corresponding scan.csv generated from the same Greenbone scan.
4. Compare findings: counts and IDs differ.
5. Click Re-import for each of the above uploads; observe that findings are closed/created unexpectedly and overall totals rise.

Expected behaviour

• XML and CSV imports of the same OpenVAS report should produce identical findings (or at least map deterministically one-to-one).
• Re-importing an unchanged file should result in zero modifications—no new findings, no closures.

Deployment method

• Docker Compose

Environment information

Newest DefectDojo OS Version

Screenshots

Sample scan files

I can supply the exact scan.xml and scan.csv that trigger the issue after redacting confidential data (company-specific hostnames, IPs, etc.). Let me know if sanitized samples would help.

Additional context

We rely on re-import in CI pipelines; the ever-increasing finding count breaks downstream metrics and dashboards. Happy to enable debug logging or test any patches you suggest.

[valentijnscholten]

I don't think the parsers (and reports) are designed to be mix-and-matched in the same test. What happens if you import an xml and then reimport the same or another xml?

[Hamudah]

Sorry if this wasn't clearly, but we didn't mix the reports. So if I use XML for just one Test and reimport the same xml test, then it has this wrong behavior. CSV has the same problem, but shows a different result.

So in short. The same report in CSV or in XML has a different result.

If you reimport the exact same report again, you get this wrong behavior, as shown in the screenshot.

[valentijnscholten]

Could you check #12378? We're looking for a good hash code configuration for OpenVAS.

[Hamudah]

Very similar to that Issue, but on top of the behavior mentioned in #12378, CSV and Xml deliver different results of the same Report. So if I create a new Test only with Xml and one only with CVS, I get different Results

[jostaub]

@Hamudah Would you mind attaching the sanitized examples to this issue? I'm currently updating the logic and de-duplication of the OpenVAS parser as part of #12378, and I'd like to check whether this issue is still present in the updated version.

[Hamudah]

@jostaub I am very sorry, I thought I already uploaded the scans. When I checked back I realized I didn't. Here is the Scan as CSV output. Somehow I can't upload the XML Version of the same Report. Github always gives me an upload failed response.

Here the CSV
20250413-CSV Results.csv

If you find something that could relate to any company, I would appreciate it, if you would let me know, so I could delete and upload another version. I sanitized it with some script, but errors are always possible.

[jostaub]

@Hamudah can i add your csv as a test case to the defectdojo git repo? (My new implementation does not seem to suffer from the described problem)

[Hamudah]

@jostaub it should be fine. I run two scanners over the file to make sure nothing is in it, which would be a problem for me. So go for it. Also thank you for your work and fixing this issue.

[manuel-sommer]

Can we close this?