Open felix-caboff opened 5 months ago
This issue has been labeled as stale
because it has been open for 30 days with no activity.
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.
Sorry, I missed this. @felix-caboff What sort of debugging are you doing? You can sort or filter findings by severity with a filter like severity_filter
in a report. There's an example in the report template sample. Is this what you're looking for?
This issue has been labeled as stale
because it has been open for 30 days with no activity.
Don't worry! Somehow I didn't see your responses either...
I was trying to not have to use the filter and instead have a Jinja2 single code block in my template that would go through all the findings, grouped by severity. This might be me being daft, but I couldn't work out a way of ordering the findings and being able to iterate over the whole lot whilst also only putting headings in for the boundaries between severity levels at the right places. At the moment it feels really clunky for my template at least because I have effectively got the same chunk of code repeated five times, once for each severity level.
This screenshot is a clipped version of one of those Jinja2 blocks to hopefully make what I mean a bit clearer.
(The above has the accompanying end ifs etc but hopefully you get the point)
Are you looking for the report context to have something like this?
{
...
"findings": [...],
"critical_findings": [...],
"high_findings": [...],
...
}
That sounds pretty sensible!
Actually, on second thought I am not sure.... (I am quite probably having a slow day - sorry!)
I think I want my template to be able to have something like this in it:
{% for severity in severities %}{{ severity.name }}{% for finding in findings %} {{ finding.title }} Issue description ...SNIP... {% endfor %}{% endfor %}
I might simply be missing something in the existing data structure or a technique or similar so this might not need a fix. Or maybe it does...
I think I'm following what you're after. You can use filter_severity
, which requires you to know the severity values. A severity key in the report context would let you do something like this to loop over the severity values (potentially in reverse) and display that severity value with findings that match that severity without knowing the specific severity name.
I've added a severities
key to the report context that produces a list like this:
"severities": [
{
"severity": "Critical",
"severity_color": "966FD6",
"severity_color_rgb": [
150,
111,
214
],
"severity_color_hex": [
"0x96",
"0x6f",
"0xd6"
],
"weight": 1,
"color": "966FD6"
},
{
"severity": "High",
"severity_color": "FF7E79",
...
It includes the same color values from a finding's severity key for things like coloring table cells based on the severity.
That sounds perfect! Thanks for the effort!
Is your feature request related to a problem? Please describe. I am hoping this is only a small change that would make debugging report template issues easier. At the moment I can't think of a way to iterate over the severity levels which means in order to group the findings by severity level i need to explicitely have a "Critical" section, a "High" section and so on. There may be a way of doing this but I can't find it in the documentation and I can't think of a simple way of doing it within the existing data structure that is made available to the Jinja2 engine. If this data is made available it would mean I could just have one instance of the content output which would mean a significant reduction in debug time when making template changes.
Describe the solution you'd like It would be ideal to have this data structure made available to the various different output functions such that the Jinja2 engine can iterate over it. As this data already exists in the back end, I am hopeful that it is an easy change.
Describe alternatives you've considered The only alternative I can think of is really complex and involves string splitting etc which is less than ideal.