OpenCTI playbooks and automation

A playbook in OpenCTI does not run as a single block of logic inside the web application. It depends on three deployment pieces working together: the platform itself, which provides the user interface and the GraphQL API, Python workers that consume RabbitMQ messages to perform asynchronous writes, and connectors that import, enrich and export data. Before you design a playbook, map each step you intend to automate to one of these pieces, because that mapping determines where the work happens, what it depends on, and how long it takes to become visible to analysts.

When a playbook changes an object, such as adding a label, setting a score or creating a relationship, the change is not necessarily written to the knowledge graph in the same request that triggered it. The platform publishes the operation as a message to RabbitMQ, and a Python worker picks it up and applies it to the data stores. Elasticsearch or OpenSearch, Redis and the knowledge graph behind them are then updated as the worker completes its work. The practical consequence is that a playbook can finish its logic while the resulting data is still queued. Under load, or when workers are scaled down, that gap grows.

This asynchronous path matters in two ways. First, timing: if a downstream playbook step, a dashboard or a TAXII feed depends on a value written by an earlier step, it may read stale data unless you design for the delay. Second, load: a playbook that fans out many updates across a large import creates a burst of queued messages that workers must drain, and that burst competes with imports and enrichment connectors for the same capacity. Your sizing decisions for workers and RabbitMQ should account for playbook volume, not only for ingestion.

Before you rely on any timing or load estimate, confirm exactly which components execute each playbook step in your release. Ask the vendor or check the release documentation for each action type, and record whether it is handled synchronously by the platform or queued to workers or a connector. Then test a representative playbook in a non-production environment and compare the execution trace with the time at which the change appears in the interface and the API. Repeat the test with a realistic import volume so you can see how queue depth behaves under the load you expect.

Treat every test run of an OpenCTI playbook as evidence. Before a playbook touches production intelligence, open the execution trace for a single known input and confirm three things for every step: that it ran, that it ran in the order your design specifies, and that it acted on the intended object, such as the indicator, report or observable that triggered the run. Walk the trace step by step against your design document. A step that ran on an object you did not expect usually points to a filter or routing defect, even when the final output looks correct. Confirm the exact status labels and field names shown in your version's trace view, because they can differ between releases.

Know what a failed or skipped step looks like before you test. A failed step normally shows an error state and stops the steps that depend on its output, so check whether the run ended there and whether any partial writes happened first. A skipped step is more dangerous because the run can still report success. A filter condition that evaluates to false, a missing field that a later step reads as empty, or a branch that is never taken will leave a step unexecuted without an obvious error. For each test case, write down the state each step should show before you run it, so an unexpected skip stands out when you review the trace.

Build the test set deliberately rather than relying on a sample of live feed data. Include ordinary inputs, then the edge cases most likely to break labeling, scoring, enrichment and routing: duplicate indicators arriving from two feeds, indicators with missing fields such as no confidence value or no validity dates, and objects carrying conflicting labels, such as both a malicious and a benign marker. For each case, record the expected final object state and the expected trace path. Use data that resembles your feeds but is sanitized. Illustratively, a duplicate pair should produce one merged object or one enrichment request, and the trace should show which of those happened.

Re-run the same inputs after every change to confirm the output is stable. After any edit to a playbook, filter, connector or scoring rule, replay the full test set and compare both the traces and the resulting objects with your baseline. Differences in step order, extra enrichment calls or changed scores need an explanation before promotion. Keep baselines and playbook exports under version control together. Also confirm with Filigran's documentation for your version how execution traces are retained, how long they stay queryable, whether they can be exported and who can review them. These answers determine whether your test evidence and production traces survive an audit or incident review. Playbooks are an Enterprise Edition feature, so the test environment must run under a license that covers them.

Every OpenCTI upgrade is a change to the automation that labels, scores, enriches and routes your data, so plan playbook testing as part of the upgrade, not as an afterthought. OpenCTI uses date-based version numbers. Regular releases follow the pattern x.YYMMDD.z, and LTS releases follow x.YYMMDD.z-lts.n, where the date is the release or LTS branching date. Non-LTS releases ship when they are ready, from daily to weekly, so a team on a regular release will meet frequent change to the platform that its playbooks depend on.

Long-term support lines give a slower and more predictable pace. According to the OpenCTI product life cycle documentation, LTS releases occur every six months and each is supported for one year, which creates a six-month overlap between consecutive LTS versions. LTS images are distributed as container images, but you need a specific LTS license key to run them. Confirm with Filigran that your license covers the LTS line you intend to run before you schedule the upgrade. After the one-month stabilization period, an LTS release receives only critical bug and security fixes, so new playbook features will not arrive on that line and you will need to move to a newer LTS line within its support window.

Three controls make upgrades manageable. First, keep a playbook change log that records, for each playbook, the OpenCTI version it was built or last tested on, its trigger, filters, actions, connector dependencies, owner and the reason for each change. Second, maintain a regression test set: a small collection of representative entities, such as an indicator, a malware object and a report, each chosen to exercise every branch of your playbooks, with expected labels, scores, enrichment results and routing outcomes. Compare the execution traces from the new version with the expected results after each run. Third, run the upgrade on a staging instance that matches production in version, connectors, enrichment credentials and a representative copy of the data, so failures appear before users depend on the result.

The most important open question is how playbook definitions migrate between versions. Confirm with the OpenCTI documentation or Filigran support whether exported playbooks import into a newer release without edits, whether a change to a trigger, filter or action type breaks existing steps, whether stored playbooks are upgraded in place during the platform migration, and whether you can roll back to the previous version after a database migration has run. Write down the answers in your change log, then test them in staging. Your rollback plan should state the backup you will restore, who approves the rollback and how long the team will keep the previous version ready before retiring it.