[Cloud Security] CNVM: Error Persists in Kibana Search with Asterisk (*) and No Double Quotes

[nick-alayil]

Kibana version:
BC4
VERSION: 8.8.0
BUILD: 63092
COMMIT: ba9b182

Describe the bug:
Kibana results in an error when searching for a field value with an asterisk (*) and without using double quotes. Even after clearing the search query and refreshing the page, the error continues to appear. The only way to resolve this issue is to log out of Kibana and log back in, which eliminates the error.

Steps to reproduce:

1. Install CNVM
2. Install agent using CloudFormation
3. Wait until vulnerability are discovered
4. Navigate to Findings page and click on Vulnerabilities tab
5. Run a search query - vulnerability.package.name : ssl

Expected behavior:
Display results matching the search criteria or show empty state with call to action for reset filters if there is no match.

Screen recording (if relevant):

Screen.Recording.2023-05-16.at.1.06.43.PM.mov

[elasticmachine]

Pinging @elastic/kibana-cloud-security-posture (Team:Cloud Security)

[tehilashn]

After syncing with @nick-alayil - this is not a showstopper for 8.8.
If we solve soon and there's another BC (due to other blockers) then it might get in.
otherwise it will be for 8.9 (and 8.8.1 if we wish)

[kfirpeled]

DOD: give a way to recover from that error

[maxcold]

Some findings after looking into the issue:

1. There seems to be a change in the logic since 8.8, now the behavior is different between Misconfigurations and Vulnerabilities. In Misconfigurations the search bar is still shown when the error occurs, so the user can recover by adjusting the search. This is in line with how for example Alerts handles this.
   Suggestion: make Vulnerabilities consistent with Misconfigurations in that regard and keep the search bar on the page in case of errors. This way the user can recover from errors
   
2. There is an unhandled exception caused by the usage of the leading wildcard symbol on the resource vulnerabilities page. The user can recover from this error by reloading the page, so it's not that critical in my opinion.
   Suggestion: I will spend some time looking into this unhandled exception, but if no quick fix is found we can create a separate bug ticket around that to track it separately

3. The usage of the leading wildcard in Kibana is configurable via `query:allowLeadingWildcards` advanced setting, which is enabled by default. Meaning the search with the leading wildcard shouldn't lead to an error. The setting is there for performance reasons, on large datasets leading wildcard search can be very expensive. Our plugin doesn't seem to respect this setting.

Suggestion: create a ticket to track the support for this setting and prioritize it separately. In my opinion, this inconsistency can be annoying for users but probably not a major problem

[maxcold]

created a draft PR fixing points 1 and 2 from my comment , will look into 3

[maxcold]

added the support for point 3 (query:allowLeadingWildcards setting). No need for separate issues to be created, if we are ok with the way of handling the leading wildcard search, I will move the PR from draft to open

[maxcold]

@nick-alayil can you take a look at this comment #157954 (comment) and check if the proposed fixes make sense? I already implemented all three, so no need for additional tickets if you agree with the fixes

[tehilashn]

Thank you @maxcold - I think everything you suggested makes sense.

[nick-alayil]

Just reviewed this ticket. Though I see it's already closed, thanks @maxcold for the thoughtful decisions and excellent work done here. Kudos! 👍

[mitodrummer]

Evidence:

Findings.-.Kibana.-.Google.Chrome.2023-08-22.16-07-31.mp4