Security teams waste precious time jumping between tools and stitching alerts together by hand. In fast-moving cloud environments, where workloads are ephemeral and scale shifts constantly, these delays drive up MTTR and create dangerous blind spots. Delays during an active threat amplify risk with every passing minute.

Sysdig has integrated with the Palo Alto Networks Cortex XSOAR platform to enhance incident management capabilities, with a strong focus on contextualization and rapid response actions.

This integration streamlines both automated and manual remediation of security incidents. Incident responders can quickly triage alerts and take precise, targeted actions at the host or container level—such as terminating compromised containers, quarantining suspicious files, or capturing detailed system activity for forensic analysis.

What can you do with Sysdig and XSOAR?

Effortlessly pull data from workloads, containers, cloud accounts, and even SaaS platforms into one cohesive view—no more chasing shadows across silos.

Automate the tedious stuff like data enrichment and case management, freeing us up to focus on the big picture.

Plus, it’s got our back with triggered response actions and system captures, firing off API calls to our backend for deeper analysis. It’s like having a Swiss Army knife that’s always one step ahead of the threats.

How the pieces fit together

Integration possibilities vary based on factors like team dynamics and technical stack. Here, we’ll outline two of the most common integration patterns:

1. Direct integration: Sysdig ↔ XSOAR

Sysdig provides real-time runtime insights, powered by Falco, across workloads in the cloud, containers, and hosts. XSOAR receives these threat notifications and triggers playbooks.

This direct approach is ideal for organizations that prioritize fast response times and want to minimize dependencies by bypassing additional layers like SIEM.

2. SIEM-integrated workflow: Sysdig → SIEM → XSOAR

Some organizations prefer to centralize all security telemetry within a SIEM before handing off to XSOAR. In this pattern:

• Sysdig forwards runtime events and threat data to the SIEM for correlation and long-term analytics.
• The SIEM then sends enriched alerts to XSOAR, which runs orchestration and response workflows.
• Response actions can still be executed via Sysdig to directly mitigate threats at the workload level.

Sysdig pack for XSOAR

Cortex XSOAR Marketplace content packs are pre-built bundles of integrations. The Sysdig content pack includes a sample playbook that serves as a blueprint, and other objects like a sample mapper – making it easier for teams to build custom playbooks tailored to their needs.

Response Actions currently supported

Through the execute-response-action command. The integration supports the following action types:

• KILL_PROCESS
• KILL_CONTAINER
• STOP_CONTAINER
• PAUSE_CONTAINER
• FILE_QUARANTINE

Captures

The create-system-capture command triggers a system capture for a particular host. This is particularly useful for further forensic analysis. Read more about Sysdig System Captures

Sysdig sample playbook in action: Automating evidence

The flow consists of different stages:

Data gathering

As we saw above, there are two ways to ingest Sysdig runtime events. The more common is to send the runtime events straight to the XSOAR platform; which could be done using the Event Forwarder or notification channel to send the events to the XSOAR webhook. The other option is to send the events from Sysdig to a SIEM solution for further enrichment and then to the XSOAR platform. In any case, we are providing an incoming classifier that will allow mapping the fields we send as part of our payload to Incident Fields, so the XSOAR platform can classify the event with the correct type.

Incident management

Based on the event or multiple events received from Sysdig, we will create a new Sysdig Runtime Event Incident. Based on the fields like the container ID, the host, and the Sysdig tenant, we will be able to run the different integration commands, including the execute-response-action to kill/pause/stop the container or quarantine a file.

This entire process can be wrapped and run automatically with a playbook. The playbook can be as complex as needed and can involve the execution of Sysdig commands to perform response actions or system captures, as well as other actions from different vendors. In this case, we are providing the Sysdig Trigger System Capture Playbook. More playbooks will be added in the next releases.

Playbook purpose: Automate system capture

The purpose of this playbook is to automate the process of taking a system capture of an affected host. The steps are as follows:

1. Validate that the incident has the required fields to take a system capture.
2. Manually ask for human approval to take a capture.
3. Call the command that will trigger the system capture with the provided details and scope.
4. Manually ask to save the capture in the incident War Room.
5. Save the .scap file.

Other real-world scenarios

Responding to crypto miners

Let’s assume Sysdig detects a crypto miner running in our environment, which triggers the Detect crypto miners using the Stratum protocol rule. Once we receive that event in the XSOAR platform, a new high-severity incident can be created. Thanks to the classifier, we can extract incident fields.

We will get an incident with the necessary fields like this. Check the incident type, the Playbook and the “Sysdig Incident Information” tabs.

The next step is to manage responding to the event. Since we don’t want a crypto miner in our environment consuming resources and generating profit for the attacker, we want to kill the container. To do that, we can run:

!execute-response-action actionType=KILL_CONTAINER callerId="soc_team" host_id="hostname-id" container_id="c000-000" Code language: YAML (yaml)

…in the War Room and manually extract the parameters needed from the incident fields.

The whole process can be automated with a custom playbook. The high-level steps for the playbook would be:

1. Check the severity of the incident and the Sysdig severity fields: high, medium, low. (This step can be omitted if all incoming Sysdig events are consistently categorized as High, e.g., 0, 1, 2.)
2. Validate that the necessary incident fields are mapped correctly and exist for the KILL_CONTAINER action type.
3. Manually ask a human for confirmation.
4. Run the command using the incident fields as parameters

Ready to try it out?

To get started with the Sysdig integration for Cortex XSOAR, head to the XSOAR Marketplace.

From there, you can install the official integration pack directly into your XSOAR environment. Once installed, register a Sysdig account by providing the required API credentials, which enable secure communication between Sysdig and Cortex XSOAR.

To install a Sysdig Response Action instance, you will need to go to Settings > Instances and search for “Sysdig”. Click on “Add Instance”.

For the URL parameter, you have to indicate your Sysdig SaaS URL; refer to the documentation for a list categorized by region.

For the API Key field, refer to the documentation on how to retrieve it, and then create an XSOAR credential entry using the following documentation.

Scroll down to the “Collect” section and select the “Sysdig Runtime Event” incident type; as well as the “Sysdig Mapper Runtime Event” for the Mapper (incoming).

Then you should see a new instance configured and enabled.

Final thoughts

Integrating Sysdig with Cortex XSOAR bridges the gap between deep runtime visibility and powerful automated response. By unifying detection and orchestration, security teams can cut through noise, reduce MTTR, and respond to threats at cloud speed. Whether starting with direct integration or a SIEM-driven workflow, this setup gives practitioners the confidence and agility needed to defend modern, dynamic environments.

‍