mitre/cti: the ATT&CK and CAPEC datasets written as STIX 2.0 bundles

A data repository with no install step and nothing to compile

The first thing to settle is what kind of project this is. There is no package manifest, no build script and no library entry point. The tree at the root is short and reads like a filing cabinet: `.github/`, `.gitignore`, `CHANGELOG.md`, `LICENSE.txt`, `README.md`, `USAGE-CAPEC.md`, `USAGE.md`, and then five data directories. Nothing in the README asks you to install anything, because there is nothing to install. You fetch the bundles and read them with a STIX library, and the README names the one it expects, python-stix2 from the OASIS open source project.

The README's first line is the honest description of the contents: the repository holds the MITRE ATT&CK and CAPEC datasets expressed in STIX 2.0. STIX, the Structured Threat Information Expression, is described in its own section as a language and serialization format for exchanging threat intelligence, with the stated goal of letting organisations share information in a consistent, machine readable way. Reading ATT&CK as STIX objects rather than as a website or a PDF is the whole point. A technique becomes an object with an identifier, a relationship to the tactics it serves, and references to the software and groups that use it, which is the form a detection rule or a data pipeline can consume.

So there is no tutorial here in the usual sense, and asking for one is asking the wrong question. The equivalent of an install guide is USAGE.md, and the project points you there in its second sentence.

Two datasets share the tree, and the README names only some of the directories

The root directory layout is where the repository stops looking like one dataset. There is `enterprise-attack/` for the enterprise matrix, and beside it `ics-attack/`, `mobile-attack/` and `pre-attack/`. None of those three names appears in the README. What the README describes is ATT&CK as a whole, defined as a globally accessible knowledge base of adversary tactics and techniques built from real world observations, and CAPEC as a dictionary of known attack patterns used by adversaries to exploit weaknesses in cyber enabled capabilities.

CAPEC gets its own section, its own usage document in USAGE-CAPEC.md, and its own directory in `capec/`. The README describes it as focused on application security, enumerating exploits against vulnerable systems, including social engineering and supply chain, and associated with Common Weakness Enumeration. That CWE association is the practical hook for application security teams: CAPEC gives you the attack side, CWE gives you the weakness side, and STIX gives you both as joinable objects.

The mobile, ICS and pre-attack directories are the quiet finding. A reader who trusts the README alone would not know those datasets ship here, and a reader who has used attack.mitre.org for mobile or industrial control system research will look for them and find them in this repository rather than the sibling one. Treat the tree, not the prose, as the table of contents.

STIX 2.0 here, STIX 2.1 next door, and both are supposed to keep running

The README contains the most consequential paragraph in the repository, and it is worth reading twice. If you are looking for ATT&CK represented in STIX 2.1, you are told to go to the attack-stix-data repository instead. Then comes the part that makes the decision yours: both MITRE/CTI and attack-stix-data will be maintained and updated with new ATT&CK releases for the foreseeable future, but the data model of attack-stix-data includes quality-of-life improvements not found here.

So this is not a deprecation notice. It is a fork in the road with a stated trade. The 2.0 layout in this repository is the long established one that existing tooling, tutorials and internal parsers already assume. The 2.1 layout in the sibling repository is the one being improved, and its documentation is what to read if you are writing new code against the data model rather than consuming identifiers from it.

A practical way to decide: look at what your pipeline actually touches. Code that maps technique identifiers to detection content, generates coverage reports or cross-references groups needs the identifiers, which are stable across both layouts. Code that walks relationships between objects, follows versioning or reconstructs the graph structure needs the data model, and that is where the improvements live. If your team cannot say which category it falls into, read the schema changelog linked from the 19.0 release notes before writing the parser. Whichever you choose, pin the version rather than following the default branch.

The release history versions ATT&CK and nothing else

The tags tell you how the project moves. The three most recent releases are ATT&CK-v19.2 published on 2026-08-05, ATT&CK-v19.1 on 2026-05-12, and ATT&CK-v19.0 on 2026-04-28. Every one of those names begins with ATT&CK, and every release note body is a pointer rather than a description, sending readers to the version history page on attack.mitre.org for the first two and to the April 2026 updates page plus a schema changelog for 19.0.

That gives you a clear picture of ATT&CK's cadence in 2026: a major release in late April, a follow-up about two weeks later in May, and the next one in early August. It also gives you a blind spot. The repository contains CAPEC, but no release tag in this list is named for CAPEC, so a CAPEC consumer has no tag to pin and no changelog entry to read. If CAPEC matters to you, the CHANGELOG.md file in the tree is the place to look for what moved, and you should expect the tag stream to tell you nothing about it.

The 19.0 notes are the most informative of the three because they link a detailed changelog and a machine readable JSON version of it, plus a summary of STIX data model changes. That is the release to read if you are upgrading an existing parser, because it is the one that tells you what changed structurally rather than what was added.

Activity is current. The last push to the default branch, master, was on 2026-08-05, the same day as the 19.2 release, so the repository is being maintained on the ATT&CK release train rather than drifting.

Where the metadata and the repository disagree

Several small mismatches between how this repository describes itself and what it contains are worth knowing before you build anything on it.

The short description reads Cyber Threat Intelligence Repository expressed in STIX 2.0. CAPEC is an attack pattern catalogue rather than threat intelligence about a specific actor, and it ships in the same tree under `capec/`, so the description covers the majority of the payload but not all of it. The topic list is narrower still: attack, cti, cyber-threat-intelligence and stix, with no capec among them. Search, topic browsing and any topic based automation will therefore not surface CAPEC from this repository, even though it is here and has its own usage document.

On licensing, the repository metadata reports no license identifier, while a LICENSE.txt file sits in the root of the tree. Read the file itself before redistributing or republishing anything derived from the data, because the absence of a machine readable license field is a metadata gap rather than a statement that the data is unlicensed. The same reasoning applies to the copyright and attribution requirements that any downstream use has to satisfy.

The absence of a homepage field is not worth much fuss, since the README carries the canonical links to attack.mitre.org and capec.mitre.org and to the STIX documentation. The open issue count is 18 against 2,151 stars and 499 forks, which is an ordinary ratio for a reference dataset where most traffic arrives through tooling rather than human reports.

How to consume it without being surprised later

Three habits make the difference between a smooth adoption and a broken pipeline six months later.

First, treat the default branch as moving. Every ATT&CK release rewrites the bundles, so a job that clones master on a schedule will see object shapes change under it without warning. Clone a version tag instead, ATT&CK-v19.2 being the newest at the time of writing, and upgrade deliberately by reading the changelog first.

Second, declare your STIX version in your code rather than inferring it. Reading a bundle as 2.0 when the upstream repository has moved to 2.1 is the failure mode this repository is most likely to cause, and it produces confusing errors deep inside a parser rather than a clean version mismatch.

Third, read both usage documents. USAGE.md covers ATT&CK and USAGE-CAPEC.md covers CAPEC, and they are separate files for separate data models. Code that assumes one set of object conventions will not transfer to the other, particularly around how patterns relate to weaknesses through CWE.

The repository is small in the way a reference dataset should be, actively maintained on a predictable release cadence, and honest in its README about the fact that a newer layout exists elsewhere. What it lacks is not substance but bookkeeping: CAPEC has no release identity of its own, and the machine readable metadata does not fully describe what is inside. Both are reasons to read the files rather than the profile.

Editorial conclusion

This is a data repository, and treating it like one removes most of the confusion. You clone it, you read bundles with python-stix2, and you judge freshness by the ATT&CK release tag rather than by anything about the code. The gaps are real but narrow. The short description and the topics list both describe a threat intelligence repository, yet CAPEC lives in the same tree and its release history is invisible in the tags. The README tells STIX 2.1 users to move to attack-stix-data and then says both projects will be maintained for the foreseeable future, which leaves the choice to you rather than resolving it. Decide it on the data model: if your tooling only reads stable identifiers such as technique IDs, the mature 2.0 layout here is fine, and if you are building new pipelines that traverse relationships between objects, read the schema changelog for 19.0 in the other repository before committing. Pin a version tag, because the default branch moves with every ATT&CK release and a toolchain that quietly tracks master will change shape underneath you.

Frequently asked questions

Official sources

1. Issues
2. mitre/cti on GitHub
3. README
4. Releases