Why add-on created with Splunk Add-on Builder is rejected on Splunk Cloud?

[pgadzhev]

It happens that Splunk Cloud rejects an add-on that was built with Splunk Add-on Builder for issues which are purely caused by the Add-on Builder code itself. The rejection is because manual checks are required on some of the generated files.

Here are the issues:

[ manual_check ] Check that all executable binary files have matching source code. For any binary files, there should be a source code provided with the same name. Or, there should be a decalaration of what the binary file is all about in the app's REAMDE. Details for passing this check will be returned if you fail it.
* Please ensure the binary files are safe. Source file: Bianry file: bin/ta_wst_monitoring_data/markupsafe/_speedups.so Format: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=bdadab1e8c314cb12636eede35fe6da16aaa198f, not stripped Source file: bin/ta_wst_monitoring_data/markupsafe/_speedups.c File: bin/ta_wst_monitoring_data/markupsafe/_speedups.so

The whole markupsafe directory was added automatically by Splunk Add-on Builder

[ manual_check ] Check if the app contain possible insecure http request in javascript files.
* The following line will be inspected during code review. ...

Bunch of JavaScript files generated by Splunk Add-on Builder are listed

[ manual_check ] Check if the app contain possible remote code execution in javascript files.
* The following line will be inspected during code review. ...

Again couple of JavaScript files generated by Splunk Add-on Builder are listed

[ manual_check ] Check that the app does not include malicious urls.
* A url telnet://192.0.2.16:80 has a scheme not in supported list(['nntp', 'nfs', 'http', 'https', 'gopher', 'ftp', 'file']) was detected in the following files. Please verify this url manually, (File: bin/ta_wst_monitoring_data/httplib2/iri2uri.py, Line: 93)

The latter is a unit test of a third-party library included by the Splunk Add-on Builder

[ manual_check ] Check that the python import method is not used in a way that can be exploited (e.g., import(conf_setting) is at risk of code injection).
* The __builtin__.__import__ function was detected being used. Please use the import keyword instead. Third-Party libraries are exempt from this requirement.

Again references to bunch of files generated by Splunk Add-on Builder

There are some other manual checks which are all related to code generated by the Splunk Add-on Builder.

Why are there such issues with add-ons generated by the Splunk Add-on Builder that cause rejections? Is there an option to have them sorted when the add-on is exported? Is there something that I am doing wrong?

Software used:
- Splunk Enterprise 7.3.0 running on Docker
- Splunk Add-on Builder 2.2.0

[sirpatrick]

@pgadzhev 

Did you ever figure this out? I just ran into it as well.

Thanks!

[chli_splunk]

When AoB 2.2.0 released, we confirmed all the issues reported by Cloud vetting with App Inspect team. They are safe and no further actions need to follow up. We didn't update AoB for 2 years, however, App Inspect team updates the vetting rules continuously.

Maybe we can ask them about this question. Also they might be able to clarify what does "manual check" mean - if their team would check these issues for users, when users can get the results; if users should check by themselves, how cloud they mark them as "passed" and unblock the app uploading, etc.