On the alliances team we encounter many questions around submitting apps for validation to appear on the X-Force App Exchange. The most common questions among them are "What is your validation process?" and "How do I prepare my app for validation?".

The answer to the first question, "What is your validation process?", is that the app validation process consists of two stages: App Validation and Secure Coding. The App Validation team installs your app, sets it up according to your documentation, sends in sample data, ensures it all gets parsed properly, and verifies that everything works and meets our best practices for apps and content packs. After that the app is sent to the Secure Coding team who vets the code for security best practices and ensures that all the packages are up to date to meet security compliance and ensure no vulnerabilities are present.

The answer to the second question, "How do I prepare my app for validation?" is answered in the following handy seven points.

1. Install your app on a fresh system with internet disabled 

Why with internet disabled? It is important to install the app with internet disabled in order to identify whether your app’s library dependencies are set up correctly; if there are issues with the library dependencies then the package manager will reach out to the internet to resolve them. Some customer environments are not able to reach out to the internet, so in these cases, your app would break on install.  

Why a fresh system? If you have not fully exported your app and content, there will be content dependencies or library dependencies missing from the package. The behavior this will produce is an app that will work flawlessly on the development system during testing, but which will have errors when installed on a fresh system. This is because some of the content or dependencies haven’t been included in the export. 

To ensure you avoid this, install your app on a fresh QRadar system and test it before submitting. Partners should note that fresh install of QRadar have a built-in 30 day license, so in this case there is no need to request another partner license for a system that is spun up and then deleted a few days later. 

If you find that the app or content pack doesn’t work properly on the fresh system, you can begin troubleshooting this by seeing if there is content that you expected to get installed but did not get installed, and then amending your export process and re-exporting the app on the development machine.  

Also note that it is ok for the content export xml to be bigger than you expect – this is largely composed of relational database dependencies that ensure the target system has all entries it needs to install the content you exported. 

Content export documentation here: https://www.ibm.com/docs/en/qradar-on-cloud?topic=content-methods-importing-exporting 

Best practices when exporting custom content: https://www.ibm.com/support/pages/qradar-best-practices-when-using-content-management-tool-export-custom-data  

2. Test your data according to your documentation

After you’ve installed your app on a fresh system, ensure you test it with the data you’ll be providing app validation to send in. Walk through the setup documentation you’ll be providing with the app and ensure all the steps are accurate, and that at the end of the setup all the events coming in properly parsed. 

3. Use Our Pre-Validation App 

We have a pre-validation app! What it does is it allows you to check for several common issues with your submission that can be easily prevented. A few examples are: 

• Python dependencies 
• CEP collisions 
• CEP naming conventions 
• Extension signing was performed properly 
• Versions in manifest.json 
• Basic security checks 
• Correct structure of extension file 

Also - when using the pre-validation app, ensure you input your X-Force exchange API credentials into the settings to ensure you have the latest data to run the app against. 

Documentation here: https://www.ibm.com/docs/en/qradar-common?topic=apps-qradar-pre-validation-app 

4. Export from the lowest version you want to support

In order to have your app compatible with the most customer systems possible, export your app from the lowest QRadar version you want to support. All higher versions of QRadar will be able to import the app as well. For example if you want to support 7.4.2FP3, 7.4.3FP2 and 7.5.0, then export the app from 7.4.2FP3 and it will work on all systems. Our lowest recommended version as of the publishing of this blog post is 7.4.1FP2. 

5. Provide unminified code for secure coding

In order to properly perform a security review on the code contained in the app, our secure coding team requires that the code is in a readable format. Examples of obscured formats are pre-built binaries and minified code files. React and other tools minify the code as part of the build process, so sometimes this cannot be avoided. 

In order for Secure Coding to perform a proper evaluation, anytime an app is submitted with minified or obscured code, the submitter will be asked to present the clear code for evaluation and to demonstrate it is the unaltered source of the minified or obscured code that will be published. 

6. Ensure libraries are up to date and not in conflict with base image libraries

This is a simple way to prevent churn in the Secure Coding process of app validation. If a dependency in your app is out of date, Secure Coding will kick it back to you to update that dependency to the newest version to gain fixes for security vulnerabilities. Simply ensure before submission that any 3rd party library you include in your app is up to date. 

The other aspect of libraries is the UBI (universal base image) dependencies. The UBI is the base image that the app is built on in the docker container. It contains a minimal set of packages to run the app framework, and the versions of its packages are updated regularly to maintain security compliance. It is important that if you are including your own version of a package that is also provided in the base image that you ensure this version is compatible with the other builds of the base image. App validation has seen apps fail, for example, because the developer included a newer version of the library “six” which does not work in QRadar 7.5.0 with the UBI version of the library “urllib”.  

In summary, if you overwrite any package that is already in the Base Image (such as six) you must verify that it works with the other UBI builds. For more information on the library versions included in each UBI build and which version of QRadar it corresponds to, please see: https://ibmsecuritydocs.github.io/qradar_appfw_v2/docs/documentation/qradar_app_base_image_changelog.html   

7. Proxy testing

If you have enabled a proxy feature in your app, an easy way to prevent churn in app validation is to ensure you test it in a scenario where your system is air-gapped.  

Sample Proxy app: https://github.com/IBM/qradar-sample-apps/tree/dc04701e26746035a87cdaa095c8553859353a50/Proxy