Update 12 parsers to have better metadata

[Jino-T]

Description

I am a Defect Dojo intern and I wrote docstrings for the 12 parsers to describe the fields it returns and to also describe the fields used for dedupe. Parsers with docstrings added are: Burp, Aqua, Bandit, Checkmarx, Cargo_Audit, Brakeman, Zap, Semgrep, Snyk, Qualys, and Gitleaks.

Note: The Aqua parser appears to have multiple versions (v1 and v2). I am unsure with which one is in use so I wrote docstrings for both but I have the v2 docstrings commented out.

[dryrunsecurity]

DryRun Security Summary

Multiple security scanner parsers in DefectDojo were updated with new get_fields() and get_dedupe_fields() methods, fixing various syntax errors, typos, and documentation issues while addressing potential security concerns like hardcoded severity values and information disclosure risks.

Expand for full summary

The PR adds new get_fields() and get_dedupe_fields() methods to multiple security scanner parsers in DefectDojo, enhancing documentation and code structure. Security findings include:

1. Checkmarx parser: Syntax error with missing comma in get_fields() method
2. Snyk parser: Missing comma separators causing potential syntax errors
3. ZAP parser: Typo in field name vuln_in_from_tool instead of vuln_id_from_tool
4. Gitleaks parser: Spelling errors in docstrings
5. Cargo Audit parser: Hardcoded severity always set to "High" regardless of context
6. Potential information disclosure through detailed parsing method documentation across multiple parsers

Code Analysis

We ran 9 analyzers against 11 files and 0 analyzers had findings. 9 analyzers had no findings.

View PR in the DryRun Dashboard.

[mtesauro]

Approved

[manuel-sommer]

Just a question: Where is the info of get_dedupe_fields returned?
And: Is it possible to load the fields directly from settings.dist.py with the help of method get_scan_types?

[mtesauro]

Just a question: Where is the info of get_dedupe_fields returned?

Right now, nowhere.

This is some early work to eventually add the ability to do checks of dedup settings against what a parser actually offers in terms of fields to dedup on.

Today, in your settings file (local_settings.py) you can do things like put line as a dedup setting for Zap.

Now, this doesn't 'hurt' the person who does this but it also doesn't make their dedup any more accurate since Zap will never report a line number like a SAST tool would.

So, before we can do things like sanity check dedup settings and provide some sort of warning that you picked a field that isn't provided by that parser, we need functions like this do DefectDojo can 'know' that.

And: Is it possible to load the fields directly from settings.dist.py with the help of method get_scan_types?

Possibly. We need to have these in place before we decide on the best place to use them. I mentioned ☝️ what my early thinking is the project hasn't really settled on the best way to use this - could be a log message, an alert, something else. That's TBD.

Make sense?

[mtesauro]

And, full disclosure, I'm the one that gave the intern this work 😏

There should me more PRs for more tools - this was their first PR in the effort.

[manuel-sommer]

Thank you for the clarification. From my point of view this is a nice feature to give feedback about deduplication settings and I would love a general way to maintain deduplication at one place, but let's see how this initative evolves.