OpenCTI: a STIX2 knowledge base for threat intelligence teams

The problem OpenCTI solves for CTI teams

Threat intelligence work produces two kinds of material that rarely live in the same place. On one side there are observables: IP addresses, hashes, domains, with first and last seen dates. On the other there are the non-technical judgements: suggested attribution, victimology, and the analyst reasoning that connects them. Most teams keep the first in a feed or a blocklist and the second in documents, tickets or chat. OpenCTI is built to hold both in one structured store and to keep every item tied to the report, MISP event or other source it came from. The README describes the goal as capitalizing technical information such as TTPs and observables alongside non-technical information such as suggested attribution and victimology, with links between each piece of information, first and last seen dates and levels of confidence. That is a specific audience: analysts who need provenance and confidence rather than a flat list of indicators. If your requirement is to push IOCs into a firewall, this is more machinery than the job needs.

How the STIX2 knowledge schema and the GraphQL API fit together

The structuration of the data is performed using a knowledge schema based on the STIX2 standards, according to the README. STIX2 is not an internal format here; it is the shape of the model, which is why imports and exports are described in terms of STIX2 bundles alongside CSV. The platform is a web application with a GraphQL API and a UX-oriented frontend, and the repository layout reflects that split: opencti-platform/ holds the platform, opencti-worker/ handles background work, and client-python/ is a Python client for the API. The root package.json is a Yarn 4 workspace driven by Nx, with targets for dev, build, test, lint and graphql, and it requires Node 22.18.0 or newer. One design consequence worth stating plainly: the README says new relations may be inferred from existing ones once data has been capitalized. Inference is a feature for representation, but it means what you see in the graph is partly derived, so an analyst has to know which edges came from a source and which were computed.

Installing OpenCTI with Docker and connecting a first source

The README does not include installation steps. It states that all you need to install the platform can be found in the official documentation, and lists four routes: Docker, manual installation, Terraform (community) and Helm charts (community). The documentation lives at docs.opencti.io, and the Docker route is documented under the deployment installation page. Because the README gives no commands, no ports and no environment variables, nothing can be quoted here as a working snippet; the honest instruction is to open the deployment page and follow it. What can be said from the repository is that the platform is a web application backed by a GraphQL API, so the first thing to confirm after the stack is up is that the API and the frontend both respond.

For programmatic access, the repository ships a Python client under client-python/. The README does not document its constructor arguments in the text available here, so check that directory for the current interface before writing code against it.

# From the repository root, the workspace targets are defined in package.json
yarn install
yarn build

Those two commands come from the root package.json scripts, which define deps, dev, build, test, lint and graphql as Nx run-many targets. They build the source tree; they are not a deployment. For a running instance, the Docker, manual, Terraform or Helm path in the official documentation is the one the project points to.

Community Edition, Enterprise Edition and what the licence actually covers

OpenCTI ships in two editions from the same platform. The Community Edition is licensed under the Apache 2, Version 2.0 license, and the Enterprise Edition is licensed under the Enterprise Edition license; both are referenced from the LICENSE file in the repository. The README says the Enterprise Edition can be enabled directly in the settings of the platform and that it adds features requiring specific investment in research and development, with the feature list on the Filigran website rather than in the repository. The repository metadata reports the licence as NOASSERTION, which is consistent with a file that carries two licences rather than one. Practically, that means a licence scan of the repository will not resolve to a single identifier, and anyone assessing the project for internal use should read LICENSE and the Enterprise Edition page instead of trusting an automated classifier. This is not legal advice; it is a note that the licence story is deliberately split.

Where OpenCTI is the wrong tool

The README states that OpenCTI is currently under heavy development and directs bug reports and feature requests to the GitHub issues module. That is a maintenance posture, not a defect, but it sets expectations: the model and the API move, and the release history in the repository shows a fast cadence with versions dated within days of each other in September 2026. Teams that need a frozen interface for years should plan for upgrade work. The second limitation is scope. OpenCTI is a knowledge management platform, not a detection engine and not a distribution mechanism. It organizes and links intelligence; it does not block traffic. A team whose only goal is to sync indicators to enforcement points will carry the cost of a web application, a GraphQL API and a worker process for no benefit. The third is the installation surface itself: with four documented deployment routes and no steps in the README, the operational burden sits with whoever runs it, and the README offers no rollback or upgrade procedure to read before you start.

OpenCTI compared with MISP

The comparison people ask about most is OpenCTI against MISP, and the README answers it indirectly. MISP appears in the integration list, not the alternative list: OpenCTI can be integrated with MISP, TheHive and MITRE ATT&CK. MISP is built around events and attribute sharing between communities, which is why it dominates indicator exchange. OpenCTI is built around a STIX2 knowledge schema that links observables to reports, attribution and victimology, with first and last seen dates and confidence levels attached. The difference in approach is the unit of work: an event versus a knowledge graph. In practice a team can run both, with MISP as the sharing hub and OpenCTI as the analytical layer that imports from it. Choosing OpenCTI instead of MISP means giving up the community exchange model for a richer internal model; choosing MISP instead of OpenCTI means keeping exchange and losing the structured provenance graph.

Maintenance cost and upgrade reality

The repository's last push was on 2026-09-21 and it is not archived, so the codebase is being changed. The recent release list shows versions 7.260917.0, 7.260914.0 and 7.260910.0 published on 2026-09-17, 2026-09-14 and 2026-09-10, which is a release every few days. That cadence is the upgrade cost. A self-hosted deployment that follows releases closely has to re-test connectors and the GraphQL surface regularly, because the platform is the integration point for MISP, TheHive, MITRE ATT&CK and the connectors listed on the Filigran hub. The root package.json pins Node to 22.18.0 or newer and Yarn to 4.18.0, so build environments have their own version floor. The README points to a rolling release package generated from the master branch at releases.opencti.io for anyone who wants to track master rather than tagged releases. The README does not document a rollback procedure, so a team that upgrades on every release should decide its own versioning policy before the first upgrade.

Editorial conclusion

Adopt OpenCTI if you already produce or consume STIX2 and need a shared, queryable store with first and last seen dates, confidence levels and source links. Do not adopt it as a quick indicator blocklist or as a replacement for an operational MISP instance feeding detections; the two solve different problems and the README positions MISP as an integration, not a substitute. Before committing, read the deployment section of the official documentation for Docker, manual, Terraform and Helm options, and check the LICENSE file for the Community and Enterprise Edition split, because the README names two licences and only the Community Edition is Apache 2.0.

Frequently asked questions

Official sources

1. Issues
2. OpenCTI-Platform/opencti on GitHub
3. Project website
4. README
5. Releases