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 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.

• Controls, AI Guardrails rules, pen test scopes, diagrams, and reports 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, adjust architecture 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.