Bug Fix: improve Kiuwan SCA parser to support multi component findings

[mwager]

This PR enhances the Kiuwan SCA Parser by modifying the logic to create one finding per component, instead of taking only the first component from the components array.

The buggy code:

Motivation

In the current implementation, for a given CVE from a Kiuwan SCA scan, only the first component listed is used to create a finding. However, many CVEs in Kiuwan are related to multiple components. This leads to loss of detail and incomplete representation of risks in DefectDojo.

Test results

• Manual test with real-world Kiuwan JSON input shows that all findings are now preserved and properly associated with the correct component.

This checklist is for your information.

• Bugfixes should be submitted against the bugfix branch.
• Give a meaningful name to your PR, as it may end up being used in the release notes.
• Your code is flake8 compliant.
• Your code is python 3.11 compliant.
• Add applicable tests to the unit tests.
• Add the proper label to categorize your PR.

[mwager]

TODO: Ideally you extend the test suite in tests/ and dojo/unittests to cover the changed in this PR.

I will soon check how to update & run unit tests, any info/docs on it appreciated :)

[valentijnscholten]

Thanks for looking into this, information on running unit tests: https://github.com/DefectDojo/django-DefectDojo/blob/master/readme-docs/DOCKER.md#run-the-tests-with-docker-compose

[Maffooch]

@valentijnscholten what do you think of this approach?

[Maffooch]

@mwager how are things going here?

[mwager]

@Maffooch Sorry, I forgot to update the tests. Done from my side now!

[mwager]

@Maffooch @valentijnscholten Does it look good to you? :)

[mwager]

@valentijnscholten should be good to go now?

cc @shodanwashere

[valentijnscholten]

We've realized that the PR will result in violations of the (logical) "unique" constraint for the unique_id_from_tool field. We're discussing how we could handle this scenario now and in the future. Possible compromise for this parser could be to store the row id in the vuln_id_from_tool field? The unique_id_from_tool is not used in dedupe currently for this parser.

[mwager]

@shodanwashere Could you have a look and discuss this with the team? Thx!

[shodanwashere]

@valentijnscholten true, since two components could have the exact same vuln, the IDs would no longer be unique. does the unique_id_from_tool have some constraint preventing it from being null? otherwise, we could go with having the id on the vuln_id_from_tool field.

[valentijnscholten]

@shodanwashere Using the vuln_id_from_tool field is acceptable in this case.

[mwager]

@valentijnscholten does it look good now?

cc @shodanwashere

[shodanwashere]

i'll assume that's what we're intending to do. @valentijnscholten will it work like how @mwager has implemented?