Open source SOAR and security automation

When open source SOAR fits a security operations team

Open source SOAR fits a security operations team when analysts receive more alerts from the SIEM, EDR and identity tools than they can triage by hand, and when the organization needs automation that keeps case data, enrichment lookups and response actions inside its own environment. Shuffle is the primary open-source option covered here. It is a general purpose security automation platform licensed under AGPL-3.0, so teams should have counsel confirm that the license terms fit how they plan to distribute or modify it. Shuffle does not detect anything by itself. It works on alerts produced elsewhere, which is why the detection sources matter to the decision. Wazuh and Security Onion are the two detection platforms most often paired with it in self-hosted designs, and each one needs its alert output, API access and retention confirmed before any playbook is written.

The decision depends on requirements, not on the tool alone. Before comparing platforms, a team should write down the alert sources it must integrate, the response actions it is allowed to automate without a human approval step, the systems those actions touch (identity provider, endpoint agent, firewall, ticketing), and who will own each playbook after go-live. If several of those answers are unclear, a SOAR platform will automate confusion. Teams should also confirm with the vendor and in their own test environment whether each required connector exists in the release they plan to deploy, or whether it must be written and maintained in-house. Commercial SOAR products may fit some requirements better, and the comparison should be made against the same written list.

DeployOpen plans, implements, integrates, hardens and supports self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks, so the SOAR platform, its connectors and its case data stay where the client controls them. DeployOpen also prepares systems and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Those come from independent auditors and certification bodies. A useful first step is a short scoping exercise that maps alert sources, candidate playbooks and approval rules to a written, fixed scope with agreed deliverables before any build begins.

Requirements to agree before choosing a SOAR platform

A SOAR platform is only as useful as the decisions behind its playbooks. The six areas below are the ones to settle in writing before comparing products, because each one narrows the platform options and shapes the build and staffing plan. Agree them with security operations, IT, legal and the owners of the systems that automated actions will touch.

Alert sources and daily volume

List every tool that will send alerts into the automation layer, such as the SIEM, EDR, email security, cloud audit logs and identity provider, along with the expected alerts per day from each. Record which sources expose APIs or webhooks and which need a forwarder or custom connector. Volume determines whether the platform must run as a clustered deployment and how much worker capacity the playbooks need. Ask each source owner for a sample of real alert payloads so integration effort is scoped against actual data.

Response actions analysts take today

Before automating anything, document what analysts do by hand for the top alert types: enrichment lookups, user account checks, host isolation, indicator blocking and ticket updates. Note the systems each action touches and how long the manual steps take. Actions that are repetitive, read-only and well understood are the strongest first candidates. Actions that change production state need a separate decision, covered in the next requirement.

Approval and change control for containment

Decide which automated actions may run without a human and which need approval, such as disabling an account, isolating a server or blocking a domain across the estate. Define who can approve, the time window for approval, the fallback when no one responds, and how each automated change is recorded in the change management system. Containment that runs unattended can cause outages, so this decision should be signed off by the operations owners of the affected systems.

Data residency and network placement

Identify where alert data, enrichment results and case records may be stored and processed, and whether any of it is personal data or regulated health or financial information. Decide where the SOAR platform and its worker nodes run and which networks they can reach, including whether they need access into segregated or air-gapped zones. Enrichment often calls third-party reputation services, so confirm which outbound destinations are permitted and which data may leave the environment.

Audit trail and evidence needs

Define what must be recorded for each automated run: the triggering alert, the playbook version, the inputs and outputs, each action taken, the approver and the result. Confirm how long run history and case records must be retained and who can read or change them. Playbook edits should be logged as well, so a reviewer can show which logic was in force when a containment action was taken. Agree these requirements with internal audit and compliance before design starts.

Skills to build and maintain playbooks

Name the people who will write, test, version and retire playbooks after go-live, and estimate their available hours in writing. Most of the ongoing work is updating playbooks when a source API, a ticketing field or a credential changes, not the initial build. Check whether the team can write Python or scripting in the platform's workflow editor, and who holds administrator access to the platform itself. Gaps here should be closed with a support retainer, an internal hire or a partner, and the choice should be made before the platform is selected.

Which open-source SOAR and detection stacks fit which teams

This table compares a dedicated SOAR platform, Shuffle, with building response workflows directly on the detection stacks Wazuh and Security Onion. Read each row against your own team size, licensing review and the detection data you already collect. Capabilities listed here must be confirmed in a proof of concept before you commit to an approach.

Option	When it fits	Licensing to review with counsel	Operating effort	What it does not cover
Shuffle as a dedicated SOAR	Several tools need orchestration (SIEM, ticketing, identity, endpoint) and a team wants a separate automation layer with its own workflow history	AGPL-3.0 (Shuffle v2.3.0, September 28, 2026). Review network-use obligations if workflows are exposed to users or partners	Ongoing playbook design, app or connector upkeep, and an owner for workflow changes after go-live	Detection content, log collection and sensor tuning remain in the SIEM or NSM tools. Confirm each connector you need
Wazuh active response and integrations	Endpoint-centric response such as host isolation or blocking through agents, with alerts already flowing from Wazuh	GPL-2.0 for the core repository (Wazuh v4.14.9, October 15, 2026). Review any bundled or add-on components separately	Rule and decoder maintenance, agent fleet management, and tuning of active response scripts	Cross-platform case management and approvals across tools outside Wazuh. Confirm whether a separate SOAR is still needed
Security Onion alerting and workflows	Teams that already run Security Onion for network and host monitoring and want response tied to Suricata, Zeek and osquery data	Elastic License 2.0 (Security Onion 3.3.0-20260911). Review restrictions on offering it as a managed service	Tuning of Suricata and Zeek alerts, Elastic stack capacity planning, and playbook logic maintained alongside the platform	Identity and ticketing actions in third-party systems unless integrated separately. Confirm supported outbound actions
Custom scripts on a SIEM or ticketing API	Few, stable response steps with a small number of target systems and no need for a visual workflow editor	Usually the license of the scripts and the libraries they use. Review any vendor API terms	Low tooling cost but high dependence on the engineers who wrote the scripts. Plan code review and version control	Audit trail, retries, approvals and reuse across teams. Each new response path becomes new code to maintain
Hybrid: Shuffle orchestrating detection platforms	Multiple detection sources feed one triage queue, and response spans endpoint, network and identity actions	Combine AGPL-3.0 (Shuffle) with each detection platform's license. Counsel should review the combined deployment	Highest integration count and the most change control. Requires named owners for each connector and playbook	Does not replace detection engineering or threat hunting. Proof of concept should test failure handling and rate limits

Which playbooks to automate first

Tier one triage is usually the best place to start because alert volume is high, the actions are read-only, and the success criteria are easy to measure. An automated playbook can collect context before an analyst opens the ticket, so the analyst begins with a verdict draft instead of a raw alert. Candidate playbooks in this group include:

Phishing mailbox triage: pull the reported message, extract sender, URLs and attachment hashes, and check them against threat intelligence before routing the case.
IP and hash enrichment: query reputation, passive DNS and sandbox results for indicators in each alert, then attach the results to the case in the ticketing system.
Duplicate and noise suppression: group repeated alerts from the same rule and host so analysts see one case instead of dozens.
Alert severity scoring: combine asset criticality and enrichment results into a suggested priority that an analyst can accept or override.

Measure the time to first analyst action and the share of alerts closed without escalation before expanding scope. Confirm with your SIEM and threat intelligence vendors which lookups are rate-limited or licensed, because those limits shape the playbook design.

Reference architecture for a self-hosted SOAR

A self-hosted SOAR sits between detection sources, identity, threat intelligence and the ticketing system, and it holds credentials for all of them. The cards below cover the components a team should design before choosing a platform, how each one connects, and where credentials and logs end up.

SOAR platform and its data store

The orchestration engine runs playbooks, stores workflow definitions, execution history and case data, and keeps uploaded files. Shuffle is one option under AGPL-3.0, and its database and object storage are separate components with their own backup and retention needs. Confirm where execution logs are written, who can read them, and whether playbook run data contains raw alert content with personal data. Plan the database as a stateful service with backups tested by restore.

SIEM and detection sources

The SOAR consumes alerts from a SIEM or detection platform such as Wazuh or Security Onion, and from network sensors built on Suricata and Zeek. Each source should send alerts with a stable identifier so that the SOAR can deduplicate and link follow-up actions to the original event. Decide which system is the system of record for alert status, because a SOAR that closes alerts in one place and not the other creates audit gaps.

Threat intelligence feeds

Enrichment lookups call a threat intelligence platform such as MISP or OpenCTI to tag indicators, reputation and related campaigns. The SOAR should cache results and record which feed and version produced each verdict, so analysts can explain a decision later. Confirm the license of any feed you redistribute, since MISP is AGPL-3.0 and OpenCTI Enterprise Edition uses a separate license.

Identity and directory services

Playbooks that disable accounts, reset sessions or add users to a group need a service account in the identity provider with narrowly scoped rights. Keycloak, authentik or ZITADEL can act as the source for SSO, while Active Directory or LDAP remains the directory of record in many estates. Document which accounts the SOAR can act on, require a named owner for each service account, and log every administrative action taken through the identity provider.

Ticketing and case management

Every automated action that changes a system should open or update a ticket, so that the audit trail lives in the case system rather than only in SOAR logs. Define which events create a case, which update an existing one, and which close it automatically. Confirm the ticketing system's API limits, webhook support and how it stores attachments, since large enrichment outputs can grow quickly.

Secrets storage for integration credentials

API keys for the SIEM, threat intelligence platform, identity provider and ticketing system should live in a secrets manager, not in playbook definitions. OpenBao (MPL-2.0) and Infisical (MIT outside ee directories) are open source options. HashiCorp Vault moved to the Business Source License 1.1 starting with version 1.15.0, which is not an OSI-approved open source license, so confirm its terms with counsel before choosing it. Rotate integration keys on a schedule and restrict which playbooks can read each secret.

Build in-house, partner, or buy SaaS for SOAR

This table compares building on open source in-house, using open source with an implementation partner, and buying commercial SaaS SOAR across the factors that matter after go-live. Read each row as a question to answer in your own environment, and use the quote requests in each cell to compare like with like. The main takeaway is that the licence line is rarely the largest cost; playbook ownership, skills and exit terms usually decide the outcome.

Factor	In-house on open source	Open source with a partner	Commercial SaaS SOAR
Control over data and code	Full control. Playbooks, logs and case data stay in your environment, and you can read and modify the source under the platform's license, such as AGPL-3.0 for Shuffle.	Same hosting control as in-house, with the partner working inside your accounts or data centers. Confirm in writing who holds admin credentials and where any partner-side tooling runs.	Data and execution typically run in the vendor's cloud. Ask where case data is stored, which regions are used, and whether connector code is open or proprietary.
Skills needed	Automation engineering, API integration, security analyst knowledge and platform operations. Expect to hire or retrain before go-live, not after.	Fewer internal hires for initial build, but you still need an owner who can approve changes, review playbooks and run incidents without the partner.	Analysts build and maintain playbooks in the vendor's tooling. Confirm whether the vendor's training, certification or professional services are included or extra.
Who maintains playbooks after go-live	Your team owns every playbook, connector update and version upgrade. Name an owner per playbook and a review cadence before the first production run.	Shared model. Ask the partner to document each playbook, hand over runbooks and define which changes they make under a retainer versus your team's own changes.	Vendor and your analysts share maintenance. Confirm who fixes broken connectors after a vendor API change and what the response commitments are in writing.
Cost structure	Mostly one-time build effort plus recurring staff time, hosting and upgrades. The software license may be zero, but the labor is the main line.	One-time scoped implementation plus optional recurring support or upgrade retainer. Request a fixed-scope quote with deliverables, timelines and exclusions.	Recurring subscription, often tied to usage or seats, plus onboarding fees. Request the pricing model, overage terms, and what counts as a billable unit.
Exit options	Strongest exit. Export playbooks as code and data from your own storage, with no contract to terminate.	Good exit if the partner delivers source, configuration, documentation and runbooks in your ownership. Confirm this in the statement of work.	Depends on contract terms. Request data export formats, playbook export support, notice periods and assistance terms for migration away from the platform.

How a SOAR rollout runs from scoping to handover

The sequence moves a self-hosted SOAR from an agreed list of use cases to playbooks that run in production under named owners. Each phase closes with a written output that the security team signs off before the next phase begins. The schedule is set in the written scope.

Scope use cases and sign off requirements
DeployOpen works with the SOC lead, incident response, IT service management owners and the platform team to list the alert types, enrichment sources and response actions in scope. The team ranks candidate playbooks by alert volume, analyst time per alert and the reversibility of the response, then records which actions may run without a human decision. The output is a signed requirements document with an explicit out-of-scope list, which becomes the basis of the fixed-scope quote.
Design environment and integration architecture
The team designs where the Shuffle platform runs inside your cloud account, data center or air-gapped network, including high availability, backup, and network paths to the SIEM, EDR, identity provider, threat intelligence platform and ticketing system. It also defines the service accounts, secret storage, least-privilege API scopes and logging of every automated action. The output is an architecture decision record and an integration inventory that your security architects review and approve.
Build and test a proof of concept
DeployOpen builds two or three playbooks from the top of the ranked list, typically one enrichment flow, one triage flow and one contained response, and runs them against replayed or sandboxed alerts. Analysts compare the automated output with their manual steps and record false positives, missing fields and failed API calls. The output is a test report with pass or fail results per playbook and a list of changes needed before production, which the SOC lead must accept.
Harden the platform for production
Before any playbook touches production systems, the team applies the hardening baseline agreed in the design: access control for the Shuffle console, role separation between playbook authors and approvers, encryption in transit and at rest, backup and restore tests, and monitoring of the automation platform itself. Your security team reviews the configuration against the internal standard and records exceptions. The output is a hardened build and a restore test record.
Enable production in stages with approval gates
Playbooks move to production one at a time, first in observe-only mode that suggests actions to analysts, then with human approval for each containment step, and only later with automatic execution for low-risk actions that the owner has approved. Each promotion requires a named approver and a review of the run log. The output is a promotion record for every playbook that shows its mode, approver and the date it changed, which also supports the audit trail.
Hand over runbooks and playbook ownership
DeployOpen delivers runbooks for operating the platform, rotating credentials, recovering from failed integrations and rolling back a playbook, and it trains the SOC and platform staff who will run them. Each playbook receives a named business owner, a technical maintainer and a review cadence agreed with your team. The output is a handover pack with an ownership register, and the support model for any retainer is defined separately in the written scope.

Systems the SOAR must connect to and what each involves

A SOAR platform is only as useful as the systems it can read from and act on. Each connection carries its own integration method, credential scope and test requirements, and these decide how far automation can safely go before a human approves the step.

SIEM alert ingestion

The SIEM or log platform is the usual source of alerts that trigger playbooks. Confirm whether the SOAR pulls alerts by API polling or receives them by webhook, and how it handles duplicates when the same event is forwarded twice. Use a read-only service account scoped to the alert and search endpoints, and not to administrative configuration. Before production, replay a week of historical alerts through the playbook and compare its verdicts with what analysts decided.

Ticketing and case systems

Every automated decision needs a durable record that an auditor or incident commander can read. Confirm whether the case system exposes an API for creating, updating and closing records, and whether attachments and comments can be written by the service account. Scope the credential to the project or queue the SOAR owns. Test that a failed update retries without creating duplicate tickets, and that closed cases cannot be reopened silently by automation.

Identity providers for account actions

Disabling accounts, forcing sign-out or revoking sessions are high-impact actions that run against the identity provider. Confirm which admin API the product exposes, whether it supports SCIM or only direct directory calls, and whether session revocation is available separately from account disablement. Grant the narrowest administrative role that covers these actions, store the credential in a secrets manager, and test against a dedicated test user before any production playbook is allowed to act.

EDR and endpoint tools

Isolating a host or collecting a process list depends on the endpoint detection platform's response API, which varies widely in what it permits. Confirm whether isolation, file quarantine and triage collection are available through the API, and whether they require a specific agent version or policy. Use a dedicated API client with a role limited to response actions on named device groups. Test isolation on a lab host first, and verify that the analyst can release it through the same path.

Threat intelligence platforms

Enrichment playbooks look up indicators in a threat intelligence platform before deciding whether to block or escalate. Confirm the query method, rate limits and whether lookups return confidence and source fields the playbook can branch on. Use a read-only key, and keep any write-back of new indicators behind a separate, reviewed workflow. Before production, measure how often enrichment returns no data for known-bad indicators, because a silent empty result can look like a clean verdict.

Email security and cloud control planes

Phishing playbooks often quarantine messages or remove mailbox rules, and cloud playbooks may revoke keys or change security groups. Confirm which mail platform APIs allow message purge or hold, and whether the cloud provider supports the specific API calls with a role that can be scoped to a resource group or account. Keep these actions in a separate approval path, test them in a non-production tenant, and document the rollback step for each action before enabling it.

What to ask an implementation partner before signing

Start with ownership, because playbooks are the part of a SOAR deployment that drifts fastest after go-live. Ask the partner to name, in the statement of work, who maintains each playbook once the engagement closes: who reviews changes, who approves edits to response actions that touch identity or endpoints, and who answers when a playbook fails at 2 a.m. Ask for a written handover of the playbook inventory, including which playbooks call Shuffle apps, which depend on a specific SIEM or ticketing field, and which are owned by your team rather than the partner. If the answer is that the partner will maintain them under a retainer, ask what that retainer covers in terms of playbook changes, testing and turnaround, and whether it is priced separately from the implementation.

Next, ask how approval gates and kill switches are tested before anything runs against production. A credible answer names the specific gate for each high-impact action, such as disabling an account, isolating a host or blocking an indicator, and shows a test record where the gate was triggered, rejected and logged. Ask how a single workflow or integration can be disabled without taking down the whole Shuffle instance, and who holds the authority to do it. Ask for the results of a dry-run against a non-production target, and whether the partner will repeat that test after each playbook change. Also ask how credentials for SIEM, ticketing and identity APIs are stored and rotated: they should live in a secrets store with scoped service accounts, not in playbook text, and the partner should explain how access to those credentials is logged.

Finally, ask about the upgrade path, documentation and price changes. Shuffle, like any self-hosted platform, will need patches, so ask how the partner tests a new release against your playbooks before applying it, how rollback works, and how they track the Shuffle release notes, such as the v2.3.0 release published on September 28, 2026, against your installed version. Ask what runbooks and knowledge transfer are included, who is trained, and whether the documentation covers the playbook logic and not only the installation. Last, ask how scope changes are priced. Every new integration or playbook should trigger a written change request with a defined scope, effort estimate and acceptance test, so you are never billed for work that was not agreed in writing.

Questions buyers ask about open source SOAR cost, effort and ownership

What drives the cost of an open source SOAR deployment?

The software license is usually the smallest line item, because Shuffle is licensed under AGPL-3.0 and can be run without a per-seat license fee. The main costs are people and infrastructure: engineering time to design and build playbooks, hosting capacity for the orchestration platform and its workers, integration work with your SIEM, ticketing and identity systems, and the ongoing hours spent testing and updating playbooks. Costs rise with the number of tools you connect, the number of alert types you automate, the compliance evidence you must keep, and the number of environments (test, staging, production). Ask any quote to split one-time build work from recurring support, hosting and maintenance, and to state which integrations are included.

How long does a first set of SOAR playbooks take to build?

There is no fixed duration that applies to every environment, so ask for an estimate built from a written scope. The main drivers are the number of alert sources you want to automate first, how many of those sources have documented APIs and working credentials, how mature your current triage runbooks are, and whether approvals must be built into the workflow. A first set that covers one or two high-volume alert types with enrichment and ticket creation is usually far smaller than a set that includes automated containment. Plan for a testing period before any playbook takes action in production, and confirm with the vendor and your team which steps they expect to own.

What does the work need from our internal team?

Your team needs to supply access, decisions and knowledge. Expect to provide named owners for each SIEM, ticketing, identity and endpoint system the playbooks touch, service accounts with least-privilege permissions, and sandbox or test instances where playbooks can be exercised safely. Analysts must document the triage steps they already perform, because those steps become the playbook logic. Security leadership must approve which actions, such as disabling an account or isolating a host, may run without human review. Without these inputs, the build stalls at credential requests and unclear decision rules.

Can an internal team run a self-hosted SOAR platform on its own?

Yes, many teams can, provided they have engineers who know containers or the platform's deployment model, someone who understands the SIEM and ticketing APIs, and analysts who can define triage logic. The risk is single-person dependency: if one engineer maintains every workflow, a departure can leave playbooks broken and undocumented. Before you decide, check whether you can cover on-call for the automation platform, patching, backups and upgrades, and whether you have a test environment to validate changes. A partner can plan, implement, document and hand over the platform, or support it under a retainer, which is different from owning it outright.

Who maintains playbooks after go-live?

The owner should be a named internal role, usually a detection engineering or security operations lead, with a backup. Playbooks break when APIs change, credentials rotate, SIEM rules are renamed or analysts change their triage method, so they need a change process, version control, test cases and a review cycle. A partner can build the playbooks and transfer documentation, or provide ongoing maintenance under a retainer that covers upgrades and fixes. Ask the partner who is responsible for each playbook at handover, how changes are tested before release, and what happens to automations that fail silently.

Does the AGPL-3.0 license affect how we use Shuffle internally?

The AGPL-3.0 license permits you to run Shuffle internally, modify it and use it within your organization. The key obligation applies when you distribute modified versions or make them available to others over a network, in which case you must offer the corresponding source code under the same license. Internal use of unmodified or internally modified code generally does not trigger that release requirement, but the exact position depends on how you deploy, customize and share the software. Have your legal team review the license text and your intended use, especially if you build custom apps that external parties will access, and confirm the position with the vendor where needed.

When is a SaaS SOAR a better choice than self-hosting?

SaaS is often the better choice when you have a small security team, no capacity to run an orchestration platform, and a mainly standard set of integrations already supported by the vendor. It can also suit organizations that prefer to pay a subscription rather than fund engineering and hosting. Self-hosting fits better when data residency rules restrict where alert data can go, when you need to run in an air-gapped network, when you want full control over connectors and code, or when you already operate the surrounding platforms. Compare total cost over the period you plan to run the service, including staff time, and confirm what the SaaS provider stores and where.

How DeployOpen scopes, builds and supports SOAR

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including automation platforms such as Shuffle. For SOAR, we start from a written list of alert types, integrations and approval rules, then build and test playbooks in the environment where they will run.

How we scope

Inventory the alert sources, SIEM and ticketing systems, and the top alert types the SOC triages each week.
Rank candidate playbooks by volume, analyst time and blast radius before agreeing which ones are in scope.
Agree in writing which actions run automatically, which need analyst approval, and which stay manual.

How we build

Deploy the chosen automation platform, such as Shuffle, in the client's cloud account, data center or air-gapped network.
Build enrichment and response playbooks with logging, error handling and credential storage in a secrets manager.
Test each playbook against replayed or sample alerts, with documented expected outcomes and rollback steps.

How we hand over

Deliver playbook documentation, integration configuration, access model and runbooks for analysts and engineers.
Train the named owners who will change playbooks, add integrations and review failed executions after go-live.
Agree a maintenance model that states who owns each playbook, how changes are approved and where they are recorded.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing of playbooks are available as a retainer.
Confirm with us the upgrade cadence, change control and support hours that apply to your environment before signing.