Fortify fpr-parser uses a wrong risk/priority calculation

[GeofoxCoding]

Hello,

Our teams discovered a wrong behavior in the DefectDojo Fortify fpr-parser. This parser was added in addition to the existing xml-parser. An fpr is a zip container and containes an audit.fvdl xml-file with issue information.

The xml is created via CLI tools or special software like audit workbench, that adds some further information to the findings like a "friority" (fortify priority rating). This information is missing in a raw fpr file.

Bug description

Inside "parse_severity_and_convert" function of:
https://github.com/DefectDojo/django-DefectDojo/blob/master/dojo/tools/fortify/fpr_parser.py
it's visible that the fpr-parser uses only InstanceSeverity and Confidence fields from the audit.fvdl.

This leads to significant higher priority ratings in DefectDojo than in Fortify itself.

Expected behavior

Other projects on GitHub are mentioned by the Fortify community and have implemented Fortifys internal scoring formula:
https://github.com/jaxley/python-fortify

They calculate the risk/friority as a result of impact and likelihood ((confidence * probability * accuracy) / 25). These values are taken from the finding class rule also contained in the same audit.fvdl / fpr-file.

It would be great if you could improve this behaviour.

[manochinnachamy]

Hello,

Firstly, I would like to express my gratitude to the community for developing a parser for FPR files. I concur with the reported bug and would like to highlight two issues related to the parsing of the FPR file that I believe would benefit all of us through a bug fix.

1. Severity Mismatch:
   I've noticed that the severity levels in DefectDojo do not align with those in Fortify, which can lead to confusion for users. Since the Fortify tool has its own logic for determining severity, I suggest updating the parsing logic in DefectDojo to adhere to Fortify's default severity order (also known as friority).

   Based on the InstanceSeverity value from the audit.fvdl file, the severity mapping is as follows:

   Instance Severity	Severity
   5.0	Critical
   4.0	High
   3.0	Medium
   2.0	Low

For example, the below finding is flagged as High severity finding by Fortify as the InstanceSeverity is 4.0

  <InstanceInfo>
    <InstanceID>D3166922519EDD92D132761602EB71B4</InstanceID>
    <InstanceSeverity>4.0</InstanceSeverity>
    <Confidence>5.0</Confidence>
  </InstanceInfo>

Unfortunately, I couldn't attach the file with the .fpr extension, so I have zipped it and attached it here.
Please modify the file extension back to .fpr if necessary. The sample FPR file contains a total of 4 findings.

Fortify_HelloWorld.zip

Here’s what I see in Fortify Audit Workbench:

And here’s what I see in DefectDojo:

2. Audits Not Considered:
   Additionally, when a security engineer audits the FPR file using Fortify Audit Workbench to mark false positives or adjust severities, these audits are not reflected when importing into DefectDojo. The audits are saved in a file named audit.xml, which references the audit.fvdl using instanceId values.

   For instance, when a finding is marked as a false positive, the corresponding instanceId is updated with the attribute suppressed=true:

   <ns2:Issue instanceId="87E3EC5CC8154C006783CC461A6DDEEB" suppressed="true" revision="0"/>

[valentijnscholten]

@manochinnachamy Thanks for your report. Can you raise a separate issue for the "audits not considered"?