Atomic Red Team maps tests to ATT&CK, then hands you the runner, the cleanup, and the grading

The library ships tests while the runner is somebody else's job

Atomic Red Team is a library of tests mapped to the MITRE ATT&CK framework, described as small and highly portable detection tests, so what you clone is content and helper scripts rather than a platform. Two execution paths get named. You can execute atomic tests directly from the command line with no installation required, or you can adopt an execution framework such as Invoke-AtomicRedTeam when you want a more complete testing experience. That split is the most important structural fact about the project. A bare checkout and a shell get you individual tests. A more robust testing experience belongs to an execution framework that you select and run yourself.

The install step is a wiki page, not a command

No installation command and no package invocation appear anywhere in the project's own documentation. Instead you get pointers: the Get Started page of the wiki for command line use, the wiki for documentation, and atomicredteam.io for the philosophy and development behind the tests. Contributors who want to add Linux atomics are sent to GitHub Codespaces through codespaces.new/redcanaryco/atomic-red-team plus a wiki page on Codespaces, and the root of the repository does carry a .devcontainer/ directory that fits that workflow, though nothing states what is inside it. The consequence for readers is concrete: nobody reaches a first executed test from a fresh clone without leaving the repository, and any automated onboarding has to transcribe the wiki steps by hand.

pyproject.toml pins Python 3.11 and files pytest under runtime dependencies

The Python side lives in pyproject.toml. It declares the package atomic-red-team at version 0.1.0, built through poetry-core, authored by Maintainers <[email protected]>, and constrained to python = "^3.11", which puts anything older than 3.11 outside the supported toolchain. The dependency table lists pyyaml ^6.0.3 alongside ruamel-yaml ^0.19.1, then jsonschema ^4.26.0, requests ^2.34.2, pydantic ^2.14.2, and typer ^0.27.3, and it lists hypothesis ^6.170.8 and pytest ^9.2.0 in that same table rather than in a separate development group. Two consequences follow: a production install of this manifest drags property-based testing libraries along with it, and two YAML parsers are always installed where a single one would serve most callers.

No GitHub releases means no tag to diff between runs

The repository publishes no GitHub releases. The default branch is master and the last push landed on November 2, 2026, so the tree moves while the package version string stays at 0.1.0, and that string describes the Poetry package rather than the contents of the atomics/ directory. There is no tag to diff, no changelog to read, and no stated way to record which revision of the test set produced a given result. The consequence for anyone running these tests against real telemetry is that you must pin the commit yourself and write down what you ran, because a detection that worked in March may now be sitting on top of a test definition that has changed underneath it.

Nothing in the library grades whether your detection fired

The project calls these detection tests, and the mapping attaches each one to an ATT&CK technique. What the mapping records is the test, not the alert it is supposed to provoke, and the README describes no scoring or reporting; the repository root holds: .devcontainer/, .github/, .gitignore, CODE_OF_CONDUCT.md, Gemfile, LICENSE.txt, README.md, atomic-red-team.gemspec, atomic_red_team/, atomics/, bin/, poetry.lock, pyproject.toml, static/. A run that finishes cleanly tells you a command executed. It tells you nothing about whether your SIEM or EDR raised an event. The consequence bites hardest in the first quarter of adoption: a team that counts technique coverage as proof of detection builds a confident and wrong picture of its own visibility, so treat the ATT&CK ID as a checklist and confirm the alert in the tool that is supposed to raise it.

No rollback documented and no platform matrix published

Two absences matter more than any feature list. First, the README does not document rollback, and the project description says nothing about returning a host to the state it held before a test. Portability here means a test is small enough to fit anywhere, not that the system comes back afterward. Second, there is no published platform matrix. Linux atomics get mentioned once, in connection with the Codespaces contribution flow, and nothing enumerates which operating systems, shells, or interpreters the test set covers, and nothing offers Kali or Ubuntu steps. The consequence for an administrator weighing this for a fleet is that the only way to learn which of their machines a given test touches is to read the atomics themselves, one file at a time, before the first run.

C, Python, and a gemspec share one repository root

The repository records C as its primary language, while the root carries atomic_red_team/ as a Python package directory next to a Gemfile, an atomic-red-team.gemspec, bin/, and static/. The project's own documentation does not say what the C source covers or what the gem is packaged for, so an adopter has to read the tree before trusting it. This is also what community development looks like in practice. Contribution runs through a Slack workspace with a code of conduct file to review first, an issue picker for bugs and feature requests, a contribution guide held in the wiki, and that Gemfile, each path maintained by people arriving from different directions. Plan reviews around a tree that several packaging systems touch.

Mapped tests will trip your own monitoring, and the docs stay quiet about it

Because the tests are mapped to techniques that ATT&CK names, they reproduce the behavior those techniques describe, and the project intends them to be run against your own environment. The README says nothing about warning your SIEM or EDR team before you start, nothing about scoping a run to a lab host, and nothing about the telemetry noise these commands create on a shared network. The consequence is operational. Schedule the window, give the monitoring team the ATT&CK IDs you are about to execute, and keep the blast radius to machines you can rebuild. A burst of ATT&CK-tagged alerts with no prior notice tends to be handled as a real intrusion, and the person running the validation ends up explaining the alarm he caused.

Editorial conclusion

Atomic Red Team fits a team that already owns its execution layer and wants ATT&CK-mapped, revision-pinnable tests it can read and vendor. It does not fit a team expecting a scheduler, coverage scoring, rollback, or a platform support statement. Before anything touches production, confirm which hosts the atomics in your chosen set actually affect, since the README does not answer that, and record the exact commit you tested against, because the project publishes no releases to diff.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. redcanaryco/atomic-red-team on GitHub