Open-source project
mitre-attack/attack-stix-data avatar
mitre-attack/attack-stix-data

attack-stix-data: the MITRE ATT&CK dataset packaged as STIX 2.1 collections

STIX data representing MITRE ATT&CK

703 stars149 forksPythonNOASSERTION

At a glance

What is it?
The MITRE ATT&CK STIX Data repository publishes the ATT&CK knowledge base as STIX 2.1 JSON collections, split by domain into Enterprise, Mobile and ICS, with a machine readable collection index. It is the reference feed for anyone building detections, threat models or CTI pipelines on ATT&CK, and the wrong choice if your tooling only parses STIX 2.0.
Who is it for?
Adopt attack-stix-data if your pipeline speaks STIX 2.1 and you want the ATT&CK dataset in a versioned, machine readable form with one collection per release and an index that tells consumers what has shipped. Do not adopt it if your tooling reads STIX 2.0 only, because that variant lives in the separate mitre/cti repository, and do not expect a live feed, since this is a set of published artefacts refreshed at release time.
Can I use it commercially?
Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
Is it still maintained?
Yes. The repository last received commits 10 days ago.
What is it written in?
Mainly Python, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.

Editorial analysis

The ATT&CK knowledge base in a machine readable form

MITRE ATT&CK is described as a globally accessible knowledge base of adversary tactics and techniques based on real world observations, and it is used as a foundation for building specific threat models and methodologies in the private sector, in government and across the cybersecurity product and service community.

This repository holds that knowledge base represented in STIX 2.1 JSON collections. STIX itself is a language and serialization format for exchanging cyber threat intelligence, and the value it adds is consistency: organisations share CTI in a machine readable way, which supports collaborative threat analysis, automated threat exchange, and automated detection and response.

So this is a data repository, not a tool. There is no server to run and no plugin to install. What you get is a set of JSON bundles that a detection engineer can load into a SIEM, a data pipeline can transform into detection rules, or a threat modelling exercise can use as a checklist of adversary behaviour.

The STIX version is the detail that decides compatibility. This repository is STIX 2.1 with the collections feature. The same dataset in STIX 2.0, without collections, is in the separate MITRE/CTI repository. That is the fork in the road for anyone evaluating it, and it is stated at the top of the documentation rather than buried.

Three domain folders, one index at the root

The layout is small and deliberate. Each domain of ATT&CK is represented as a series of STIX 2.1 collection bundles for the individual releases of the dataset, organized inside its own collection folder.

The enterprise-attack folder holds the Enterprise data, with a file named enterprise-attack.json that is a collection bundle without version markings, and it always matches the most recent release of the dataset. Alongside it sit the versioned files, for example enterprise-attack-9.0.json, one per release. The mobile-attack folder holds the Mobile releases and ics-attack holds the releases for ATT&CK for ICS.

At the root sit two index files. index.json lists the contents of the repository in a machine readable format, and index.md lists the same contents in a human readable format.

Two design choices are worth calling out. First, the unversioned enterprise-attack.json means a consumer that always wants the latest data has a stable filename to point at, which is what a scheduled pipeline wants, while the versioned files give you reproducibility, which is what a detection rule author needs when they want to say which release a rule was written against. Second, the split by domain means you download only the matrix you care about. A team working on ICS or on mobile does not have to pull the Enterprise bundle, which is the largest part of the dataset.

A collection is one release, and the index is how you find out about new ones

Collections are sets of related ATT&CK objects, used to represent a specific release of a dataset, such as Enterprise ATT&CK v9.0, or any other set of objects you want to share with someone else. Each ATT&CK release in this repository is itself a collection, and the full list of them is in index.md.

Collection indexes are the organised lists that make distribution to consumers practical. They track individual releases of a given collection, for example Enterprise v7, v8 and v9, and they allow applications such as the ATT&CK Workbench to check whether new releases have been published. The index is represented as JSON objects, and index.json is the ATT&CK collection index for the contents of this repository.

This is the mechanism that makes the repository usable in automation. A consumer does not need to poll three directories and compare modification times. It reads index.json, sees which collection identifiers exist, and downloads only what it does not already have. The index is also the piece that makes offline and mirrored use workable, since a mirror can serve its own copy of index.json and let clients discover the rest.

The human readable index.md is not a convenience afterthought either. When an analyst wants to know which release contains a given object, reading markdown is faster than parsing JSON, and the two are kept in step.

Getting the data and querying it with cti-python-stix2

There is no installation step here, and it is worth being explicit about that rather than inventing a package manager command. The project gives you three ways in.

First, the raw files. Clone the repository, or fetch a specific bundle over HTTP, and you have STIX 2.1 JSON on disk. The index.json file at the root gives you the machine readable catalogue of what is available and where.

Second, the USAGE document, which includes documentation of the ATT&CK data model as well as code examples for accessing and querying this content with cti-python-stix2, the Python library for STIX 2. That is the path to follow if you want to load bundles into a Python process, traverse the objects, and build your own queries rather than grepping JSON.

Third, the util folder, which holds additional information and tooling for maintaining the data in the repository. That is aimed at contributors rather than consumers, but it is a fair signal of how the dataset is produced, since the same tooling is what keeps a release consistent.

For a quick first look, the smallest useful step is to open index.json, pick the collection identifier for the domain you work in, and download the corresponding versioned bundle. Nothing about that requires an account, a token or a registry.

Releases land on a versioned cadence, and each one is a new collection

The release history is a versioned sequence tied to ATT&CK content versions rather than to software releases. v20.0 was published on 2026-10-13, v19.2 on 2026-08-05 and v19.1 on 2026-05-12. The repository is not archived and the last push was on 2026-10-13.

The practical consequence for a consumer is that the identifier changes. A detection rule pinned to a collection identifier for a specific version keeps working, but a rule that always resolves the latest Enterprise bundle changes underneath you when a new release lands, because the content has changed. Whether that is a feature or a hazard depends on whether you want new techniques as soon as they exist or a frozen behaviour set for validation and testing.

The repository also carries a CHANGELOG.md at the root, which is where you look to see what a given release changed rather than diffing bundles yourself.

One structural constraint is worth noting for tooling authors. The dataset is not one file, it is a family of collections across three domains with two index formats on top. A consumer that assumes a single flat JSON document will need rework, and that is the practical difference between this repository and the STIX 2.0 variant.

Licence, terms of use and what redistribution asks of you

The licence is the part that needs reading rather than assuming. The repository is recorded as Other, a custom licence that GitHub cannot classify, and the actual terms live in the LICENSE.txt file at the root. The documentation also carries a Notice with the copyright line for 2020 to 2025 The MITRE Corporation, the statement that the data is approved for public release, and a case number. The project states that it makes use of ATT&CK and links the ATT&CK Terms of Use.

So there are two documents in play, the repository licence file and the ATT&CK terms of use, and the safe approach is to read both if you intend to ship the data inside a commercial product or redistribute it. This is not legal advice, and it is not a claim that the terms are restrictive. It is a reminder that the data is published for public release, which is not the same thing as published without conditions.

The name of the project is also trademarked in a sense. The project states that it makes use of ATT&CK, and a product built on this dataset should treat the ATT&CK marks as third party marks, which is a habit worth forming early.

Where this dataset stops being the answer

Three situations call for something else.

The first is STIX version compatibility. If your collection pipeline, SIEM connector or data lake ingester only handles STIX 2.0, this repository is the wrong source even though the underlying content is the same. The MITRE/CTI repository holds the same dataset in STIX 2.0 and without the collections feature, and for a flat, single file, version agnostic consumption that is the better fit. The cost of choosing wrong here is a rewrite of your ingestion layer, not a configuration tweak.

The second is a need for live change notification. This repository publishes releases. It is not a feed, it does not push updates to your collector, and there is no stated service level for how quickly a new ATT&CK version appears after MITRE publishes the underlying content. If your workflow needs to know about new techniques within minutes, you have to build that polling yourself, using index.json as the trigger.

The third is a need for guidance rather than structure. ATT&CK is a knowledge base of observed adversary behaviour, and this repository gives you the objects and their relationships. It does not tell you which technique matters in your environment, how to write a detection for it, or what your coverage gap is. That analysis is yours, and tooling such as the ATT&CK Workbench, which the documentation names as a consumer of the collection indexes, is where some of that work happens.

Finally, remember what this is not. It is a reference dataset with a versioned history, not a scanner, not a blocking tool and not something that changes the security posture of a system on its own.

Editorial conclusion

Adopt attack-stix-data if your pipeline speaks STIX 2.1 and you want the ATT&CK dataset in a versioned, machine readable form with one collection per release and an index that tells consumers what has shipped. Do not adopt it if your tooling reads STIX 2.0 only, because that variant lives in the separate mitre/cti repository, and do not expect a live feed, since this is a set of published artefacts refreshed at release time. Verify first that index.json lists the release your tooling expects for the domain you need, and read LICENSE.txt together with the ATT&CK terms of use before redistributing the data in a commercial product.

Frequently asked questions

What does the attack-stix-data repository contain?

It contains the MITRE ATT&CK dataset represented in STIX 2.1 JSON collections, organized into the enterprise-attack, mobile-attack and ics-attack collection folders, with an index.json collection index and an index.md human readable index at the root.

What is the difference between attack-stix-data and the MITRE/CTI repository?

attack-stix-data holds the same dataset in STIX 2.1 with the collections feature, while MITRE/CTI contains the same dataset in STIX 2.0 and without collections. If your tooling only parses STIX 2.0, MITRE/CTI is the compatible source.

How do I find the latest ATT&CK release for a domain?

The unversioned enterprise-attack.json bundle in the enterprise-attack folder always matches the most recent Enterprise release, and the versioned files such as enterprise-attack-9.0.json pin a specific release. The root index.json lists the contents of the repository in machine readable form, and index.md lists the same in human readable form.

How do I query the ATT&CK STIX data in Python?

The repository's USAGE document documents the ATT&CK data model and gives code examples for accessing and querying the content with cti-python-stix2. The util folder carries additional tooling for maintaining the data in the repository.

What licence applies to the MITRE ATT&CK STIX data?

The repository carries a custom licence recorded as Other that GitHub cannot classify, with the terms in the LICENSE.txt file, and the documentation also references the ATT&CK Terms of Use along with a notice that the data is approved for public release.

Official sources

  1. Issues
  2. mitre-attack/attack-stix-data on GitHub
  3. Project website
  4. README
  5. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/mitre-attack-attack-stix-data.svg)](https://hysenlabs.com/projects/mitre-attack-attack-stix-data)

Was this useful?