Added Preprocessing Script for Wazuh API and Modified Wazuh Parser

[ghost]

⚠️ Note on feature completeness ⚠️

We are narrowing the scope of acceptable enhancements to DefectDojo in preparation for v3. Learn more here:
https://github.com/DefectDojo/django-DefectDojo/blob/master/readme-docs/CONTRIBUTING.md

Description

This PR introduces the wazuh-vulns-extractor.py script, designed to enhance vulnerability reporting from Wazuh. This script ensures precise targeting by intersecting two specific agent groups and appends an 'agent_ip' field for every vulnerability. The updated parser.py utilizes this data, enabling DefectDojo to create endpoints and effectively correlate each vulnerability to a specific agent, streamlining traceability and accountability.

Test results

• The changes have been locally tested with sample Wazuh v4.5.2 (latest) vulnerability reports.
• The modifications do not disrupt the overall functionality of the parser.

Checklist

• Make sure to rebase your PR against the very latest dev.
• Features/Changes are submitted against the dev.
• Bugfixes are submitted against the bugfix branch.
• The PR name is meaningful and relevant.
• The code is flake8 compliant.
• The code is python 3.11 compliant.
• Proper documentation has been included.
• Model changes include the necessary migrations.
• Added applicable tests to the unit tests.
• Proper labels have been added.

Extra information

Moderators: Kindly add the labels:

• Import Scans (for updated scanner/importer)
• enhancement
• feature

Contributors: Git Tips

Rebase on dev branch

If the dev branch has changed since you started working on it, please rebase your work after the current dev.

On your working branch mybranch:

git rebase dev mybranch

In case of conflict:

 git mergetool
 git rebase --continue

When everything's fine on your local branch, force push to your myOrigin remote:

git push myOrigin --force-with-lease

To cancel everything:

git rebase --abort

Squashing commits

git rebase -i origin/dev

• Replace pick by fixup on the commits you want squashed out
• Replace pick by reword on the first commit if you want to change the commit message
• Save the file and quit your editor

Force push to your myOrigin remote:

git push myOrigin --force-with-lease

[quirinziessler]

@vd0n any thoughts about adding verified=Trueto the Finding (starting line 66)? That way, the findings would be listed in the endpoint view as well. Currently an endpoint can have dozens of findings but if you look up the endpoints, it seems they don't have any.

[ghost]

@vd0n any thoughts about adding verified=Trueto the Finding (starting line 66)? That way, the findings would be listed in the endpoint view as well. Currently an endpoint can have dozens of findings but if you look up the endpoints, it seems they don't have any.

This should remain optional. Anyone can set verified=True if they upload the findings through the API or select it from the GUI, using the dropdown, and choose True.

[kiblik]

Parsers, where DefectDojo approaches some tool's API, are implemented differently. They use models like Tool Configuration and API Scan Configuration.

Please find inspiration in parsers starting with api_ like api_blackduck, api_cobalt, api_sonarqube and others.
https://documentation.defectdojo.com/integrations/parsers/api/

[quirinziessler]

As API importer caused some issues in the past and are also not wished until v3 I guess this way is a good approach to go. It should be implemented as API importer in the future (v3 ongoing) but not for now.

[quirinziessler]

I tested various upload cases and found some issues with the deduplication (see recommendations). If you integrate those and change the deduplication in settings.dist.py to Unique_id_from_tool everything works fine.

[manuel-sommer]

Hi @vd0n,

It would be nice if you could extend the unittests for this PR.

[mtesauro]

While this is a interesting PR, we can't accept API integrations while we're working on the v3 updates - details in this GH discussion: #8974

Additionally, API integrations are very hard to test with GH actions unless we run instances of all the APIs we integration with (or have accounts with commercial vendors).

Since you can obviously write code, until we get the product parent/child thing figured out and rev to version 3, this would be best implemented as an external service and called via a cron job or similar.

Thanks for the work but the timing just isn't right.