Roadmap of "grouping of Findings (and push to JIRA)"

[macedogm]

Hi 👋🏻

I made some manual tests with the feature of grouping the findings and pushing to Jira - #4017 - and it's really good. It's only missing the API and a way to automate the grouping.

Is there any planned roadmap for when it will be generally available?

If no, is there any tracking of the missing features?

I might be able to help, because this feature is really valuable for my work.

Best regards.

[valentijnscholten]

You can automatically create groups during import/reimport since #4353, or did you have another way to create groups in mind?
The idea was to get some feedback first before going all the way, but yes we should add API methods to make the grouping more feature complete.
Any other grouping related features you're missing?

[macedogm]

@valentijnscholten Thanks for your reply and comments. After testing a bit more, I believe that they way that the grouping is being done through the import/reimport API is really the best way. I don't think that another way would be better than what is already available.

My main concern now is more about being confident that the current API and logic is stable enough. To give you a bit more of context, in my current work we scan daily more than 200 repos and containers and reimport the scans in DefectDojo (we rely heavily in the reimport logic to close fixed issues and reopen reintroduced findings). We are also managing around 1000 Jira tickets (one ticket for each finding). Due to the current volume, we would love to group the findings based on the component, so the number of Jira tickets would be greatly reduced, making the management of the tickets and developer experience smoother.

With that in mind, if we "migrate" to the grouping of findings, I must be sure that the implementation is stable for production use and that the logic will not change (at least not soon).

Another question that I have is (I haven't tested this yet), when enabling the grouping, if DefectDojo will take care of deleting the old Jira tickets associated to each finding or not.

Have you already used this setup on a similar environment (in terms of numbers)?

[valentijnscholten]

It won't delete old tickets, it might even skip findings that already have a ticket connected, but I'm not sure. But it will update "group" tickets when findings are closed or new findings are created.
We have no plans to make big changes, but I haven't done a lot of production testing yet.

[macedogm]

So the best migration strategy would possibly be:

1. Close all tickets in Jira.
2. Delete the tickets in DefectDojo through jira_finding_mappings API.
3. Do a reimport with the grouping feature enabled.

When I have available time I'll test it. If you would like to do some specific testing, please let me know and I might be able to support you.

[cw-alexcroteau]

Hi! I'm also trying to use finding groups to automate creation of JIRA issues, similar to @macedogm. Our use case is similar, but we also have multiple projects which can be managed by one team. We would like to further reduce the number of tickets, by having a finding group which covers multiple products/tests and creating a new ticket automatically in our CI/CD pipeline (using the API), for example once per week per team.

I outlined a few missing features in order to achieve this goal.

1. No API endpoints are registered for findings groups. I'd like to add API endpoints to automate at least their creation and linking new findings to them.

2. Right now, findings groups are per-test (implying per-product). Is it something that I could change? I'd really prefer finding groups to be global, maybe with the option of selecting which product/test they apply to. The goal is to be able to report findings from multiple projects which are related in the same JIRA issue.

For # 1, is there any reason why the endpoints were not created/exposed?
For # 2, I know this is an architectural change, as findings groups were not necessarily meant to be global. One of the challenges would be that right now, the findings groups feature reports to the JIRA Instance linked to the product. For the finding groups to be global, I think the link should be between a finding group and a JIRA instance. Other than that, I don't see any adverse effect on having them multi-project. Any thoughts?

[valentijnscholten]

#1 is already answered above
#2 the reason for this is that jira configurations are on the engagement level. so it would be possible to change the grouping to be at the engagement level. but above that you can run into different jira configurations because they can differ per engagement or product. do you have any ideas on how that could be solved? the reason I chose the test level for is that it's easiest to display in the UI. If you have a group covering multiple tests, the UI part might become confusing. Do you have any suggestions on how to solve that?

[cw-alexcroteau]

Thanks for this fast answer!

For #1, I'm not sure the current automation fits our goal. The group_by currently supports component_name, which can be great, but we really need to group by something custom. The "create" and "add to" features in bulk edit really fits this requirement right now, but we can't automate it because it is not exposed in the API. So, to be clear, the feature I'd like to expose as API would be the "create" and "add to" as we find it in the bulk edit. Maybe there is another way to achieve the same result?

For #2, I think there are two way to fix the issues.

First way, I think putting the groups at the engagement level would not be a problem for UI. Right now, when we open the findings view of an engagement (for example /product/{PRODUCT_ID}/finding/open), bulk edit shows "Group (Only available in per test for now)". We could display the options to set findings groups in this view also. Because this view doesn't show the groups in the top section, we could eventually add a menu on engagement-level to manage the finding groups. Because we remain on the engagement level, we don't have to worry about JIRA configuration.

Second way, we could add a global view for finding groups in the sidebar, where we could add findings groups which fits in multiple engagements. If we open the "create" or "edit" view from there, there would be an option to select a JIRA config, the same way as when we edit an engagement/product. The finding group would then be available in every "add to" dropdown, of we could have a second drop down for global ones.

Of course this menu item could be further nested, it is only a suggestion.