Know how you will be attacked before you write the code. AttackTree is a Spec Kit extension that turns a feature spec into an attack tree: who attacks, what they want, and every path that gets them there. It simulates which security controls actually cut those paths. It writes the controls into the spec as testable requirements and verifies each one with evidence after implementation.
📖 Documentation: hupe1980.github.io/spec-kit-attacktree
Actor ─▶ Goal ─▶ AND/OR path ─▶ Attack vector
│
└─▶ Control ─▶ CR-### requirement ─▶ Task ─▶ Evidence ─▶ Residual risk
A threat list says what can go wrong. An attack tree says how an attacker gets from where they start to what they want, following Bruce Schneier's method and Christian Schneider's scenario-driven practice. That lets it:
- rank threats by the path an attacker would really take, per attacker profile;
- find choke points, where one control cuts every path to a goal;
- expose single points of failure, the controls your defence depends on alone;
- prove controls work, recomputing risk from verified controls only, including measured bypass rates for guardrails.
specify extension add attacktree --from https://github.com/hupe1980/spec-kit-attacktree/archive/refs/tags/v0.1.0.zipRequires Spec Kit 1.0 or later and Python 3.11 or later with PyYAML, or uv. It works with every agent Spec Kit supports. Other install sources, the companion preset, and the workflow are covered in Installation.
| Run after | Command | Result |
|---|---|---|
/speckit-specify |
/speckit-attacktree-model |
attack-tree.yaml, attack-tree.md, and CR-### requirements in spec.md |
/speckit-plan |
/speckit-attacktree-model --from-plan, then /speckit-attacktree-simulate |
attacks tied to real files; residual risk, choke points, a control roadmap |
/speckit-tasks |
/speckit-attacktree-check |
16 deterministic checks plus semantic review; Markdown, JSON, or SARIF |
/speckit-implement |
/speckit-attacktree-converge |
verdicts from evidence, verified controls, remediation tasks |
Agents on Spec Kit's dotted style spell the commands /speckit.attacktree.model. All seven lifecycle hooks are optional.
Try it on the shipped example without an agent:
python3 scripts/python/attacktree.py --repo examples/agent-assistant --feature-dir specs/001-agent-assistant simulateThe quickstart walks through the output.
The engine needs no LLM, so checks and simulation run in CI. The bundled action uploads findings to code scanning as SARIF and can fail while a goal stays at blocking risk:
- uses: hupe1980/[email protected]
with:
feature-dir: specs/007-agent-assistant
fail-on-blocking-goals: "true"See CI and code scanning.
The install writes .specify/extensions/attacktree/attacktree-config.yml with safe defaults. The most common changes:
profiles: [default, agentic] # add the agentic profile for LLM and agent features
enforcement: strict # CRITICAL findings and blocking goals stop /speckit-implement
risk:
block_on: [critical, high] # residual risk levels that blockEvery key is documented in Configuration.
| Get started | Introduction · Installation · Quickstart |
| Concepts | Attack trees · Risk model · Simulation · Verification |
| Guides | Workflow · CI · OTM interop · Agentic systems · Troubleshooting |
| Reference | Commands · Engine CLI · File format · Checks · Profiles · Glossary |
| Project | Design and roadmap · Security · Releasing |
Issues and pull requests are welcome. Before opening a pull request:
uv run --python 3.11 --with pytest --with pyyaml --with jsonschema pytest -q # the engine and manifests
zola --root site check # the site, if you changed itKeep CHANGELOG.md current, and bump extension.version and catalog.json together on every release; the tests check that they agree. The site lives in site/ and is built with Zola; preview it with zola --root site serve.