[Feature] Findings API Enhancements

[riysaxen-amzn]

Is your feature request related to a problem?
The current challenge involves users being unable to view all findings in the Findings page when dealing with a large volume of generated data/Findings. Despite the backend accurately producing all findings, some are not visible in the UI. To remedy this, it is essential to implement proper pagination in the UI.

What solution would you like?
To alleviate the pagination challenge on the UI, a backend modification is proposed for the findings/_search API. Currently, findings are generated per detector, with parameters such as detectorId, detectorType, table (including sortOrder, sortString, missing, size, startIndex, and searchString). To enhance efficiency, the suggestion is to adapt the backend to return findings for all detectors collectively. This modification would consolidate the data, allowing the frontend to implement pagination more effectively. With this approach, pagination efforts can be concentrated on the UI side, simplifying the user experience when navigating through extensive findings.

What alternatives have you considered?
A clear and concise description of any alternative solutions or features you've considered.

Do you have any additional context?
Add any other context or screenshots about the feature request here.

[amsiglan]

Along with consolidating all the findings we should support additional filters in the API like time range, finding severity and detection type (rules vs threat intel)

[eirsep]

Plz add detail around the proposed change in the findings API.
What new parameters are being added?
what existing parameters are we marking as optional?

[amsiglan]

Plz add detail around the proposed change in the findings API. What new parameters are being added? what existing parameters are we marking as optional?

1. With the proposed changes, the query params that would become optional are detector_id and detectorType. Currently we require at least one of these, so we make both optional.
2. New query params we want to support (all optional):
   a. startTime
   b. endTime
   c. severity
   d. detectionType

[eirsep]

Plz link documentation change issue here for changing findings apis

[eirsep]

Plz add detail around the proposed change in the findings API. What new parameters are being added? what existing parameters are we marking as optional?

1. With the proposed changes, the query params that would become optional are detector_id and detectorType. Currently we require at least one of these, so we make both optional.
2. New query params we want to support (all optional):
   a. startTime
   b. endTime
   c. severity
   What will be the default sorting that should be returned? latest findings first?

d. detectionType
isn't this already supported?

[riysaxen-amzn]

Plz link documentation change issue here for changing findings apis

Documentation issue link