Splunk SOAR apps overview

Splunk SOAR apps provide a mechanism to extend Splunk SOAR (Cloud) by adding connectivity to third-party security technologies in order to run actions. Given the broad set of technologies that can be orchestrated during a cyber response exercise, apps provide some relief in allowing users and partners to add their own custom functionality.

Splunk SOAR apps are developed by engineers knowledgeable in Python and modern web technologies.

There are two methods to develop your own apps for Splunk SOAR

Both methods are described in this manual.

Splunk SOAR app architecture

This architecture pertains to all Splunk SOAR apps, regardless of whether they were created with the Splunk SOAR SDK or with the Splunk SOAR App Wizard.

Splunk SOAR apps are written in Python to create a bridge between Splunk SOAR (Cloud) and other security device/applications. Think of them as having two strict edges:

  • One of the edges is given an action to be carried out on behalf of Splunk SOAR (Cloud).
  • An app on the opposite edge converts the action into specific commands to communicate with its device or service.

The result of these actions are read by the app and passed back to Splunk SOAR (Cloud). This simple design helps facilitate automated actions that are carried out by Splunk SOAR (Cloud) on behalf of the user.

This screen image shows three boxes. These boxes are Splunk SOAR, App, and Device/Service. The action arrows connect Splunk SOAR to App, and App to Device/Service. The result arrows connect Device/Service to App, and App to Splunk SOAR.

The first edge is implemented by a rich set of Python APIs that the platform exposes to the app developer through a base class.

Apps distributed by Splunk SOAR or third parties are transmitted as .gzip archives that you can import into Splunk SOAR.

Adhere to inactivity limits

avoiding time outs with your apps

Note: This information is relevant to all connectors you create or clone, regardless of whether you use the Splunk SOAR SDK or the Splunk SOAR app wizard.

Splunk SOAR apps, also called connectors, have an IPC (Inter-Process Communication) inactivity limit. Be sure that your apps send progress, status, or completion messages to the SOAR platform every 5 minutes. Otherwise, SOAR treats the app as unresponsive and terminates the action, resulting in a generic error like Failed to read message from connector.

Note: An app action can run longer than 5 minutes, as long as it continues to communicate progress to the platform. This is not a maximum action duration.

Keep the following considerations in mind when working with apps:

  • When creating or cloning an app, make sure that any long-running actions periodically report progress to Splunk SOAR. Use the send_progress() and save_progress() APIs for progress reports. For details, see App authoring API in this guide.

  • If you are using polling, paging, batch processing, or remote requests, design them so the app reports progress, and is not silent, for 5 minutes.

  • When possible, design a single blocking remote operation to use a bounded timeout or an asynchronous polling design.

  • When creating playbooks, make sure that playbook actions or logic loops do not override the IPC inactivity limit of the app. For additional details on creating playbooks, refer to the appropriate documentation for your deployment type: