Splunk SOAR community playbooks are versioned by branch, not by release

One repository per platform version, selected automatically

The repository is not a single set of playbooks but a family of them, one per Splunk SOAR release. The README describes the default initial playbooks and custom functions for each Splunk SOAR instance, and states that the platform automatically links to the branch of the repository that matches the running Splunk SOAR version. Older instances synchronise with older branches, and the README names 5.4 and 4.10 as examples of those. The platform side has one convenience: by default the repository is named community, which can be selected as the Repo filter on the playbook listing page so that only these playbooks and custom functions are displayed. Content is refreshed with the Update from source control button on the same listing page. The naming history matters for reading the README. Splunk SOAR was previously known as Phantom, the repository lives under the phantomcyber organisation, and the README calls it the Splunk SOAR Community Playbooks repository. The default branch is 8.8, so a reader should check which branch their own instance will pull before drawing conclusions from any file in the tree.

Every playbook is a triple of JSON, Python and a screenshot

The top-level layout makes the format obvious. Each playbook occupies three files with a shared base name: a JSON definition, a Python file holding the custom function, and a PNG image. Looking at the visible entries, AD_LDAP_Account_Locking appears as a .json, a .png and a .py, and the same triple repeats for AD_LDAP_Account_Unlocking, AD_LDAP_Entity_Attribute_Lookup, AWS_IAM_Account_Locking, AWS_IAM_Account_Unlocking, Azure_AD_Account_Locking, Azure_AD_Account_Unlocking, Azure_AD_Graph_User_Attribute_Lookup, Automated_Enrichment, Attribute_Lookup_Dispatch, Active_Directory_Disable_Account_Dispatch, Active_Directory_Enable_Account_Dispatch and Check_Point_EM_Credential_Leak_Validation, among others. The ANYRUN_Sandbox family is organised by both input and platform, with separate entries for file analysis on Android, Linux and Windows, and URL analysis on the same three. The convention makes the tree searchable by eye: a reviewer can see at a glance that a playbook, its code and its illustration are present and aligned, and the naming pattern makes it obvious which identity provider a playbook targets. The PNG is not decoration, since the contribution process requires a screenshot alongside the exported playbook.

What the shipped playbooks actually do

The catalogue covers identity containment, sandbox analysis and enrichment, which is the shape of a security operations response library. Account lock playbooks exist for Active Directory and LDAP, for Azure AD, and for AWS IAM, and there are dispatch playbooks that disable and enable Active Directory accounts. Lookups and enrichment fill in the middle: AD_LDAP_Entity_Attribute_Lookup, Azure_AD_Graph_User_Attribute_Lookup, Attribute_Lookup_Dispatch and Automated_Enrichment pull additional context about identities and indicators before or after a containment action. The ANYRUN sandbox playbooks submit artefacts to a sandbox and bring back the analysis, split by file or URL and by operating system. Check_Point_EM_Credential_Leak_Validation and Check_Point_EM_IOC_Enrichment_and_Triage cover a different vendor, checking credential leaks and triaging indicators. The naming pattern for account actions follows the same shape everywhere, which is a useful signal for a security team: a lock playbook that exists for AD probably also exists for Azure AD and IAM, and the review burden of adding one is largely the same.

Contributing a playbook means exporting from a running instance

The contribution process is the part that tells you what these files really are. The steps are: clone the repo and create a new branch, export the playbook from the Splunk SOAR system, unpack the exported .tgz file and add it to the playbooks folder, include a .png screenshot of the playbook, open a pull request into the default branch, ensure the automated tests are resolved and make changes as needed. After the tests pass, a Splunk SOAR Community repo maintainer reviews the submission. Two things follow from this. First, the JSON and Python in the tree are not hand-authored source in the usual sense, they are the exported representation of something configured in the product, which means the authoring tool is the SOAR UI rather than an editor. Second, the automated tests are the gate that catches a broken playbook before a human reviewer looks at it, and the process explicitly asks the contributor to resolve test failures rather than hand them over. Playbooks in the community repo are developer-supported, which is a narrower commitment than vendor support.

Where this repository is the wrong choice

The main limit is that this is content, not a framework. It is a set of playbooks and custom functions for one specific commercial platform, and there is no documented way to run them outside a Splunk SOAR instance, so a team on a different SOAR product or on homegrown automation gets nothing reusable from it. The second limit is the version coupling. Because the platform selects the branch by version and the branches are not merged into one, a playbook that exists on the 8.8 branch may not exist at all on an older branch, and a playbook that does exist may behave differently, since it was written and tested against a specific release of the platform. That coupling is the design, and it is the right design for the platform, but it means the library is only as good as the branch coverage of the version you run. The third is the trust question. The catalogue contains playbooks that lock accounts, disable Active Directory accounts and disable AWS IAM credentials, and a community repository of that kind can only be as trustworthy as its review process and its tests. The README describes that process, and it is developer-supported rather than vendor-guaranteed, so a security team should read the steps of any containment playbook before enabling it in production.

How it differs from writing your own or buying a pack

The obvious alternative is to author playbooks inside your own Splunk SOAR instance and keep them in a private repository that you version and review yourself. The difference in approach is where the review and testing work happens and who maintains it. With the community repository, a maintainer reviews pull requests and the automated tests run on export, so you inherit fixes and improvements from other users of the platform and you get coverage across identity providers you may not have staff to write for. With your own repository, you own the maintenance, but you also own the compatibility problem, because a playbook you wrote against one version has to be reworked when you upgrade. The other alternative is a commercial playbook pack sold per vendor, which typically comes with vendor support and narrower vendor coverage. The community repository is wider and free, and the trade is that it is supported by the community and carries the constraints described above. For a team that already runs Splunk SOAR and wants a starting library rather than a blank canvas, the community repository is the cheaper first step.

Editorial conclusion

Adopt the community repository if you run Splunk SOAR and want the default playbooks and custom functions rather than writing response automation from scratch, and let the platform pick the branch that matches your version. Do not copy files across branches by hand, since a playbook is written against a specific SOAR release. Before you rely on any single playbook, check that the branch matching your instance is the one you are reading, since the default branch is 8.8 while the README text describes the 6.3 branch, and review the security-relevant steps of account locking and sandbox analysis playbooks before enabling them.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. phantomcyber/playbooks on GitHub
4. README