A real, working execution engine for CACAO — the OASIS industry standard for machine-readable security playbooks (the SOAR equivalent of what Sigma is for detections) — paired with an AI generator that turns a plain-English incident response description into a real, validated CACAO playbook, and an honest map of the 18 major SOAR platforms on the market.
This is the SOAR counterpart to SIEM-Tool-Matrix — same philosophy, same honest split between what's executable and what's researched, applied to orchestration and response instead of detection.
Most "SOAR portfolio projects" show a diagram. This one runs.
cacao/schema.py— validates playbooks against the real OASIS CACAO v2.0 structure (start/end/action/if-condition/parallel steps). One deliberate simplification, stated plainly: the full spec requires step IDs in stricttype--<UUID>format; this project uses readable IDs likeaction--3-quarantineinstead, for legibility when you're reading a playbook JSON directly — full UUID compliance would be a one-line change if this were headed to productionengine/executor.py— walks a validated workflow end to end, branches on conditions, fans out on parallel steps, and returns a full step-by-step traceengine/conditions.py— a condition evaluator that deliberately does not useeval(). Even though today's conditions are all authored by this project, building the habit of never executing arbitrary strings as code is worth the extra 40 linesengine/commands.py— every response action (isolate host, disable account, quarantine file...) is dry-run by design, logging what it would do — same destructive-action boundary kept in every other repo on this profile- 3 real CACAO playbooks ship with the project: phishing response, compromised account response, and malware host isolation — each schema-valid, each ATT&CK-mapped, each tested for both branches of their conditional logic
Run it: Live Executor tab → pick a playbook → Run → watch the actual branching path the engine takes, animated node by node, not a canned demo sequence.
Describe an incident response process in plain English. An LLM (Claude by default, OpenAI supported, mock mode needs no API key at all) generates a real CACAO playbook — validated on two levels before it's ever shown or run:
- Structural — does it match the CACAO schema?
- Semantic — does every action it references actually exist in this project's command registry? A model confidently inventing a plausible-sounding action name is a real failure mode for LLM-generated automation, and it's caught, not silently trusted.
tests/test_full_platform.pyincludes a test that deliberately feeds the generator a hallucinated command name and verifies it's rejected.
This mirrors a real approach used in 2026 academic research on LLM-assisted transformation of legacy playbooks into CACAO format — not a speculative use case invented for a portfolio.
Enterprise (Cortex XSOAR, Splunk SOAR, Sentinel Automation, IBM SOAR, Google SecOps SOAR, Swimlane, Tines, D3 Security, FortiSOAR, Rapid7 InsightConnect, Torq, BlinkOps, Siemplify) and open source (Shuffle, StackStorm, TheHive+Cortex, SaltStack, Node-RED) — authoring style, native playbook format, licensing, and what makes each distinct, researched from public 2026 documentation.
One correction worth knowing for an interview: Siemplify no longer exists as a separate product — Google acquired it and folded it fully into Google Security Operations SOAR. Both are listed here explicitly to note that, since they're still often referenced as if separate.
As of 2026, no commercial SOAR platform natively supports CACAO — which is exactly why this project builds its own executor instead of relying on a vendor platform to prove the concept.
The same phishing-response playbook, shown as it would look in three platforms with genuinely different authoring philosophies: Cortex XSOAR and Microsoft Sentinel (low-code visual), and Tines (code-first, version-controllable JSON). Illustrative and sourced from public docs — not tested against live tenants, and not claimed to be.
git clone https://github.com/Aditya-Sec/SOAR-Playbook-Matrix.git
cd SOAR-Playbook-Matrix
pip install -r requirements.txt
cp .env.example .env
python app.py
# open http://127.0.0.1:5000Works out of the box in mock mode — no API key needed to try the generator or executor. Set LLM_PROVIDER=anthropic (or openai) in .env for real generation.
python tests/test_full_platform.py20 checks: schema validation, both branches of the phishing playbook's conditional logic, parallel-step execution, AI generation (including the hallucinated-command rejection test), matrix data integrity, and every route.
Proves: you understand how playbook-driven security automation actually works structurally — branching, parallel execution, the vendor-neutral standard the industry is slowly converging toward — and you can build and validate an AI generation pipeline with real failure-mode handling, not just a happy-path demo.
Doesn't prove: production experience configuring any of the 18 commercial platforms. That distinction is stated here the same way it's stated in every other repo on this profile — because a claim that falls apart under one follow-up question does more damage than not making it at all.
MIT — see LICENSE.