Publishing Your QRadar App in the IBM Security App Exchange

Custom integration apps for QRadar can be submitted to the IBM Security App exchange for greater usage and visibility

Brief Overview

Custom integration apps for QRadar can be submitted to the IBM Security App Exchange for greater usage and visibility. The process of submitting a QRadar app to the exchange is a fairly streamlined process. It takes approximately 4-8 weeks before the app is published and appears in the exchange for other users to view.

The Process

The process for submitting your application to the exchange follows these 3 main stages listed below:

1. Sign in with your IBM Partner ID at [https://www.ibm.com/account/reg/uk-en/login?formid=urx-30243]

2. Submit your app to the IBM App Submissions team. For more details on this:

2.1 Go to the “App Exchange”.

2.2 Go to “Submission Portal”

2.3 Create a new submission request for your app, by clicking on the + button

3. Once complete, this will begin the submission process.

Note: The IBM team might reject the app sometimes if they have any review comments. You need to modify the app for the suggested changes and re-submit the app.

The App Submission Stage: A Detailed Look

At the third stage listed above, the IBM App Submissions team puts your app through a rigorous process of testing.

The elements that are of importance for this process are listed below:

Secure coding. The code base for your app is reviewed to ensure there are no apparent vulnerabilities or other issues.
Separate tabs are used for HTTP and HTTPS for Proxy Settings. As part of this, HTTPS should be selected by default rather than HTTP.
Ensuring that the REST endpoint for debugging and returning the app logs is reachable.
Ensuring there is CSRF support for endpoints.
Ensuring there is CORS support for endpoints.
Ensuring there is a SEC token for all calls to the QRadar APIs. This includes AQL calls, for instance.
Ensuring that all third-party libraries used in the app are updated to their latest version to minimise vulnerabilities. Ideally, this should be checked at the time the app is submitted as well as during the process as some libraries may go out of date before the process is complete. For instance, for Bootstrap, you can review the latest version here: https://getbootstrap.com/
Ensuring there are no unused and extraneous files (such as third-party JavaScript packages) in your file.
Ensuring that all coding guidelines are followed (as per https://developer.ibm.com/qradar/2018/01/15/secure-engineering-qradar-app/).
Running source code validation tools (notably Pylint and Bandit) through your code, ensuring there are no major errors and warnings.
Ensuring that any app updated from the QRadar SDK v1 to SDK v2 has been submitted as a new app rather than an update to a previous app, as SDK v2 apps are not backward compatible.
Ensuring that any app updated from the QRadar SDK v1 to SDK v2 has generated the manifest.txt from the submission portal. This includes ensuring that the ‘id’ field has been replaced with the previous version so that it may replace the previous version of the integration as needed.
Providing credentials to IBM while submitting the app for testing.
Ensuring that any rules and offences have been updated within the app.
Ensuring all UBI apps follow the same naming convention of [APP-NAME]– QRadar v7.3.3FP6+/7.4.1FP2
Ensuring that secret keys have not been stored in plain text files. Rather, it is recommended that the qpylib.encdec library is used for storage. Examples can be found on https://github.com/IBM/qradar-sample-apps/blob/master/PostgreSQL/app/__init__.py#L41 and https://www.ibm.com/support/knowledgecenter/SS42VS_SHR/com.ibm.appfw.doc/c_app_fw_encdec.html
https://github.com/IBM/qradar-sample-apps/tree/master/Encryption
Ensuring the container/pip/requirements.txt does not contain “>=” before the library version. It should have “==” for the package version to avoid any docker build errors.
Ensuring Flask ‘jsonify’ is used to jsonify the response while returning it from a Python endpoint.