This post is a general warning to app developers using select fields, multi-select fields, and textarea fields as function inputs in their apps. All IBM developed apps have been updated to resolve this issue. If you aren't a SOAR app developer you can safely ignore this post.

Overview & Fix

It was brought to our attention today (with the QRadar Search function of the QRadar Integration for SOAR) that version 49.0.4423 of the SOAR Python Libraries introduces a change to the resilient_lib.validate_fields function which may affect function inputs that are select, multi-select, or textarea type which are processed manually. In this post I'll outline the very simple fix and below I'll go into detail on why this is happening.

Simple fix:

If you are writing apps and using select fields or textarea fields, you should already be using the static methods exposed by the parent class of each function component. Those methods are self.get_select_param and self.get_select_param respectively. These methods will handle the input properly and return the desired value as a string for select and textarea fields and a list of strings for multi-select fields.

Deep dive:

The cause of the issue is in our handling of inputs when passed to resilient_lib.validate_fields which we are now modifying in place to preserve the new app config secrets manager options. This reason for this small change is to accommodate the new secrets managers and to improve the memory footprint of SOAR apps as we are reducing allocations across the lifespan of a function. To fully understand what is going wrong, let's take the example of a select field. Select fields used for function inputs in Playbooks (or workflows for that matter) arrive to the @app_function or @function decorated method as dictionaries with a "name" and an "id" field, as they would be represented in the platform. This is distinct from text fields, boolean fields to name a few, which arrive as their expected value. So, for example, given a select field called "qradar_search_all", the value that will be passed to the app function would look like:

qradar_search_all = {
    "id": 1234
    "name": "Yes"
}

where the "id" field is only used for internal purposes on the platform, and the "name" holds the actual value desired for qradar_search_all. The static helper helper method self.get_select_param will properly extract the "name" value and return "Yes" no matter the version of resilient_lib. The newest updates to resilient_lib, extract the "name" value directly so that qradar_search_all="Yes".

Conclusion

Hopefully that sheds some light on what went wrong today with the QRadar Integration and how this might be avoided in future development. We recommend that all app developers working with custom apps that might handle select, multi-select, or textarea fields use the above mentioned helper methods to properly extract the values from the inputs and avoid issues with these down the road.

Thanks!