Allow Setting Desired Rating Scheme for Reports/Clients

[er4z0r]

As a template maintainer I would like to keep the number of different templates to a minimum so I don't have maintain consistency among them.

One issue I'm currently facing is that reports need to look differently depending on the rating scheme. For example, when I use CVSS, the will be some extra lines/cells/whatever in the header of a finding to accommodate the score and the vector. When I'm not using CVSS I do not want to see in a non-CVSS report.

Describe the solution you'd like
As a template maintainer I would like to be able to access the desired rating scheme for a report from within the template so I could include/exclude different parts of the report. Example

{% if rating_scheme==”cvss3” %}
   cvss findings header goes here
{% else %}
   simple findings header goes here
{% endif %}

Describe alternatives you've considered
Right now I either mantain an extra template for CVSS or I just create one template that has the CVSS stuff in it which I then need to remove after the export. In both cases it results in extra effort.

Once the tagging feature has rolled out, this could be used to implement a short-term solution. However, in the long run, I think making it a model property might be better:

• tags are created by the users which might make spelling mistakes so rating:cvss3 might become rating:cvss, rating:cssv etc.
• tags might be there or not be there

Also creating a full-blown model-property like rating_scheme might allow for some useful business-logic down the line such as:

• (optionally) preventing export unless all findings have a (CVSS) rating
• warning users when they add a finding from the library that does not hat a CVSS rating configured
• defining the rating scheme as a property of the client and propagating it to the report, while still allowing it to be overwritten on a per-report basis.

[chrismaddalena]

Thanks for submitting this as a feature request. I appreciate all the details and thought. Tags should help here, but you are right to assume tags may contain typos or be absent. Some other mechanism would be good to have for tracking something like this.

[chrismaddalena]

@er4z0r I think this request is covered by custom fields released in v4.1. Does a custom field work for you?

[er4z0r]

It sort of is. We can specify the rating scheme in a dedicated field now as opposed to a tag which makes it easier to spot and allows us to set a default value. One issue I can still see is the potential for typos e.g., if one of my colleagues misremembers or mistypes the value (e.g. cvvs3, cvss_3etc.) the template looking for cvss3 won't pick up on it.

I think I saw list/dropdown types mentioned as a future addition to custom fields. Is that correct?

[chrismaddalena]

I'd like to support dropdown options. That would be a neat field. Maybe we can do something like track select options in the extra field spec and use that to fill a select field. Where it might be tricky is ensuring a submitted option is valid when submitted through the GraphQL API or if someone manually alters the field in the form POST data. The latter wouldn't break anything, but we'd need to add some validation that checks if the value for a select field is in your list of allowed options.

Any thoughts @ColonelThirtyTwo ?

[github-actions]

This issue has been labeled as stale because it has been open for 30 days with no activity.

[github-actions]

This issue is closed because it has been inactive for 14 days since being labeled stale. Feel free to re-open the issue with a comment. If this needs further discussion (e.g., a feature request), it might be better to open a topic under the Discussions tab.

[chrismaddalena]

This issue is closed but tracked on the road map. Adding a select box as a custom field was also brought up in #477.