> For the complete documentation index, see [llms.txt](https://docs.devarmor.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devarmor.com/modules/threat-modeler/threat-model-versions.md).

# Version Control

Iterate on a threat model over time, and compare versions.

A threat model isn't a one-time snapshot — a project's architecture and risk profile change as the application evolves, and DevArmor tracks that as new **versions** of the same threat model.

A project can contain multiple threat models, and each threat model can have multiple versions.

## Why Version Control Matters

Security decisions age. A control that was sufficient six months ago might not be anymore — new components get added, integrations change, and the threats relevant to your architecture shift. Without version control, a threat model is just whatever it currently says; there's no way to know what it said when a given control, rule, or risk acceptance was actually made.

Version control gives your security measures **provenance**. Every control, [AI Guardrails](/modules/code-reviewer/ai-guardrails.md) rule, penetration test scope, diagram, and report in DevArmor is tied to the specific threat-model version that produced it — not just "the threat model" in the abstract. That matters most in exactly the moments provenance gets asked for:

* **Audits and compliance reviews** — show that a specific control existed and was reviewed as of a specific version, not just that it exists today.
* **Incident review** — answer "what did we know before this shipped, and was this risk knowingly accepted?" by looking at the version that was current at the time.
* **Design review** — see exactly what changed since the version your team last signed off on, instead of re-reviewing the whole system.

## How DevArmor Supports It

* Versions are numbered with semantic versioning (`v1.0.0`, `v1.1.0`, `v2.0.0`, …), and each new version explicitly records the version it was created from as its base — a documented lineage back through prior versions, not just a flat, unordered list of snapshots.
* A new version reuses the architecture from its base version instead of regenerating it from scratch, and its description carries over automatically — so creating one only requires describing what's actually changed.
* Repositories linked to a project are shared across all of its versions rather than duplicated per version, but you can still manage which repositories apply to a specific version.
* A **Compare versions** toggle on each of the Threats, Controls, and Risks tables switches that table into a diff against the previous version — grouped into added, edited, and removed items, with the specific fields that changed called out on each edited item. See [Review Threat Model Output](/modules/threat-modeler/review-threat-model-output.md#comparing-versions).
* Controls, AI Guardrails rules, pen test scopes, diagrams, and [reports](/modules/threat-modeler/reports-and-exports.md) are all associated with the version that produced them, so you can trace a rule enforced on a pull request, or a finding in a report, back to the exact threat-model version and architecture that justified it.

## Creating a New Version

1. Open the threat model you want to branch from.
2. At the top of the page, open the version selector (it shows the current version) and choose **New** at the bottom of the list.
3. In the **Create Threat Model version** dialog, DevArmor suggests the next major, minor, or patch version based on the version you're branching from — pick one, following the same convention as semantic versioning elsewhere (patch for a small correction, minor for a meaningful addition, major for a significant redesign).
4. Confirm. DevArmor creates the new version with the base version's architecture and description carried over, and takes you to it — from there, revisit [Verify Application Attributes](/modules/threat-modeler/verify-application-attributes.md), adjust [architecture](/modules/threat-modeler/architecture-and-diagrams.md) if needed, and re-run findings.

## Deleting

You can delete a single version of a threat model, or delete an entire threat model (all of its versions) at once. If a resource you're trying to delete has other items depending on it, DevArmor tells you exactly what those dependent items are before you proceed.