Migrating from IriusRisk to DevArmor
Amir KavousianTable of Contents
Why teams move from IriusRisk to DevArmor
IriusRisk helped establish automated threat modeling. It is built around a model many AppSec teams know well: draw the system on a diagram canvas, let a rules engine compute threats and countermeasures from that diagram, then track the countermeasures through an issue tracker.
That model was designed for a world where architects drew systems and engineers wrote code at human speed. Today, designs start as PRDs, design docs and tickets, and more and more of the code is written by AI agents. A threat model that lives on a canvas, maintained by hand, drifts away from what actually ships.
DevArmor starts from a different premise: the threat model should be the control plane for development, not a separate artifact. DevArmor builds it from the evidence you already have and carries its requirements through every stage of delivery:
- Threat Modeler: builds a structured threat model in minutes from PRDs, design docs, diagrams (even photos), tickets and code repositories. Your team verifies and approves each step.
- Design Reviewer: reviews every new Jira ticket and Google Docs design against that threat model and posts security requirements where engineers plan.
- Code Reviewer and AI Guardrails: checks every pull request against those same requirements, and turns them into rule files and editor diagnostics so AI coding agents follow them while writing the code.
The result is one continuous chain from design intent to merged code. That chain is the main reason teams migrate, and it is what this guide helps you set up.
Who this guide is for: AppSec leads, security architects and platform owners who run IriusRisk today and are evaluating or planning a move to DevArmor. The first half explains how the platforms differ and maps concepts; the second half is a step-by-step migration and first-30-days plan.
Two approaches to threat modeling
The biggest difference is where the threat model comes from and what happens to it afterward.
| IriusRisk | DevArmor | |
|---|---|---|
| Starting point | Diagram-first. Components are dragged onto a canvas (or imported from diagram and IaC files), then threats are computed from the diagram. | Evidence-first. PRDs, design docs, Jira tickets, diagrams and repositories are analyzed; architecture and threats are generated, then verified by your team. |
| Threat engine | Deterministic rules engine with a large library of built-in rules that teams extend and maintain. | AI agents grounded in your architecture, policies and approved patterns, with human approval at each step. No rule library to maintain. |
| Keeping current | Model changes when someone updates the diagram. | Model is versioned and re-run as documents and code change; connecting repositories shows the system as built, not only as drawn. |
| Where requirements go | Countermeasures are synced to issue trackers as tickets. | Requirements go to Jira, into design reviews of every new ticket and design doc, into pull request checks, and into AI coding agents. |
| Proof it was done | Countermeasure status and test state tracked in the platform and tracker. | Code Reviewer checks the code itself against each control, on every PR, with design-to-code traceability. |
| Who uses it | Primarily security architects and threat modelers. | Security teams, engineers in Jira, Google Docs, GitHub and their editor, and AI agents through MCP and rule files. |
What this means in practice:
With a diagram-first tool, the security team spends its time building and maintaining models, and enforcement depends on engineers closing tickets. With DevArmor, the model is built for you in minutes, and enforcement happens automatically where code is designed, written and reviewed.
Concept map
Most IriusRisk concepts have a direct DevArmor counterpart. Where the approach differs, the notes explain how the same need is met.
Structure and organization
| IriusRisk | DevArmor | Notes |
|---|---|---|
| Organization / tenant | Organization | The unit of risk management, typically one per CISO. |
| Business Unit | Team | A group that plans and prioritizes security work together. Org settings control what context is shared across teams. |
| Project | Project | A product, feature or service with its own release cadence. A project can hold several threat models. |
| Threat model (and Blueprint) | Threat model | DevArmor has no separate draft tier; you can generate, review and discard freely before approving. |
| Version History, pin-to-compare | Threat model versions + Compare versions | Semantic versions (v1.0.0) with recorded lineage. The compare view shows Added / Edited / Removed threats, controls and risks, field by field. |
| Global and project roles | Organization roles within the Org → Team → Project hierarchy | Access is scoped by the hierarchy; SSO via Okta, Microsoft Entra ID, OneLogin and Google. |
Architecture
| IriusRisk | DevArmor | Notes |
|---|---|---|
| Components | Components | Inferred from documents, diagrams and code, then verified in the Decompose step. |
| Trust Zones | Trust zones and trust boundaries | Trust boundaries are modeled explicitly, so threats that cross them are easy to trace. |
| Data Flows | Data flows | Inferred and editable; shown in the generated architecture diagram. |
| Assets, Security Classifications | Data stores and data handled by each flow | Sensitive data (PII, cardholder data, and so on) is captured as part of the architecture and drives threat and privacy analysis, including DPIA support. |
| Diagram canvas (Draw.io based) | Generated architecture diagram | Diagrams are generated, then edited. There is no blank-canvas drawing mode; you describe or upload, and DevArmor draws. |
| Model Questionnaire | Describe step | Answer in plain language what the system does, who uses it and what data it handles, or simply upload the design doc. |
| "Jeff" AI assistant | Architecture generation from any source, MCP server, VS Code / Cursor extension | AI is the core engine, not an add-on, and is available in the tools your teams already use. |
Threats, risks and countermeasures
| IriusRisk | DevArmor | Notes |
|---|---|---|
| Threats (STRIDE-LM, MITRE ATT&CK, CWE) | Threats (STRIDE, MITRE ATT&CK) | Each threat names the affected components. |
| Weaknesses | Threats and control gaps | DevArmor does not keep weaknesses as a separate object; the same information lives on the threat and the controls that address it. |
| Countermeasures | Controls | Each control can be mapped to multiple compliance requirements. |
| Countermeasure status (Recommended, Required, Not Applicable, Rejected) | Control status and priority; requirements vs. recommendations in design reviews | High-criticality items become security requirements; lower-criticality items are recommendations. |
| Inherent / Current / Projected risk | Risks with consistent scoring | Risks capture business impact with a defined formula, so they are comparable across models. Progress is tracked through control status and PR enforcement. |
| Tests and test state | Automated tests, manual tests, pen test scopes | Automated tests become policies the Code Reviewer checks on every PR, so "implemented" is verified in code rather than self-reported. |
| Standards Library | Compliance mappings | Map controls to frameworks such as SOC 2, ISO 27001, PCI DSS, NIST CSF, GDPR and HIPAA. |
Customization, workflow and output
| IriusRisk | DevArmor | Notes |
|---|---|---|
| Rules Engine and custom rules | Organizational Memory, org policies, approved design patterns | Instead of writing condition/action rules, you give DevArmor your policies and patterns in plain language; every threat model and review uses them. |
| Risk Pattern Libraries | Organizational Memory and Secure Building Blocks | Reusable org context and pre-approved patterns that humans and AI agents build from. |
| Templates | Import + Organizational Memory | Start new models from your imported ones and shared org context. |
| Issue tracker sync (Jira, Azure DevOps, ServiceNow, CA Rally) | Jira (push and sync mitigation actions), REST API | See where the platforms differ for other trackers. |
| Reports (PDF, XLS, CSV, HTML) | Threat Model Analysis report, Attack Surface Analysis report | Export to PDF, JSON and Google Docs; full data through the REST API and MCP. |
| XML data-model export | REST API and MCP server | Structured access to every object for BI, GRC or ASPM tools. |
| Workflow states | Human approval at each step + versions | Architecture, threats and controls are reviewed and approved before anything is enforced. |
Where the platforms differ, and what DevArmor offers instead
IriusRisk has several capabilities that DevArmor does not offer as a dedicated feature today. We would rather you hear it from us. For each one, here is how DevArmor customers meet the same need.
| IriusRisk capability | How DevArmor customers meet the need |
|---|---|
| Drawing on a blank diagram canvas | DevArmor generates the diagram from what you already have and lets you edit it in Mermaid or via updating its editable database. Most teams find that uploading the design doc or connecting the repository is faster and more accurate than drawing, and it catches drift between the drawing and the code. |
| Native IaC and diagram-file import (Terraform, CloudFormation, Visio, Lucidchart, MS TMT) | Upload exported diagrams as images or PDFs, which DevArmor digitizes into an editable diagram, or connect the repository that holds your infrastructure code. IriusRisk projects themselves come across through the structured XML import. |
| Issue trackers beyond Jira (Azure DevOps, ServiceNow, CA Rally) | Jira is supported natively. For other trackers, the REST API and MCP server expose every mitigation action; talk to us about your tracker. |
| Custom fields and bulk status edits | Capture business context (owners, business units, data classes) in Organizational Memory, where it shapes every analysis rather than sitting in a field. Bulk changes can be scripted through the API. |
| A large, pre-authored standards and rules library | DevArmor does not need thousands of rules to find threats. Compliance mappings cover the major frameworks; bring your own control catalog and policies and DevArmor applies them. |
| Platform audit log and project archiving | Every threat model is versioned with recorded lineage, so the history of each model is preserved. Talk to us about audit reporting requirements. |
What IriusRisk does not do
These DevArmor capabilities have no documented equivalent in IriusRisk, and they are where most of the value of migrating comes from:
- Pull request enforcement. The Code Reviewer checks every PR against the threat model's requirements, posts one consolidated comment with impact and fix guidance, and can open a fix PR.
- Design review on every ticket and design doc. New Jira tickets and Google Docs designs are reviewed automatically and natively inside Jira or Google; security only sees what needs a human.
- Security requirements inside AI coding agents. AI Guardrails generate rule files for Cursor, Augment Code, Claude Code and Codex, and the MCP server lets any MCP client drive DevArmor.
- The threat model in the editor. The VS Code and Cursor extension shows open controls as diagnostics next to the code.
- Models built from documents, tickets and code, with no code required. Model systems before they are built, from a PRD alone.
- Organizational Memory that compounds. Organization memory carries security context across all touchpoints, including Threat Modeling, Design Review, and Code Review. Your team focuses on what matters (setting up the overarching policies) rather than ferrying information between platforms.
- Built-in privacy review. A Privacy Impact Assessment is generated as part of the analysis report.
The pipeline is the point: Threat Modeler → Design Reviewer → Code Reviewer. A countermeasure in IriusRisk becomes a ticket that someone has to remember to close. A control in DevArmor becomes a requirement on the next ticket, a check on the next pull request, and an instruction to the next AI agent that touches the code.
Migrating your data
DevArmor imports structured threat model data, including IriusRisk's XML export. Imported projects arrive as normal DevArmor threat models: you verify them, enrich them with documents and code, and then put them to work.
Step 1: Plan the migration
- Inventory. List active IriusRisk projects, their owners and business units. Note which are still under active development.
- Prioritize. Pick 3 to 5 high-value, actively developed applications for the first wave. Archive-only projects can move later, or stay as exported records.
- Map your structure. Decide how IriusRisk business units map to DevArmor teams, and projects to DevArmor projects (usually one to one).
- Collect custom content. Note any custom rules, risk pattern libraries, custom standards and custom fields you rely on. You will carry their intent into DevArmor as policies and org context (Step 6).
Step 2: Export from IriusRisk
- Project data as XML. Use IriusRisk's data-model XML export for each project, or its bulk XML export from the project list. This is the primary migration input and carries components, trust zones, data flows, threats and countermeasures.
- Supporting files (optional). Export current reports (for example the Current Risk Summary and Technical Countermeasure Report) as PDF or CSV for your records and for the verification check in Step 4.
- Diagrams (optional). Export diagrams as images if you want a visual reference alongside the import.
Step 3: Set up DevArmor and import
- Set up the organization. Configure SSO, create teams to match your business units, and create projects.
- Connect integrations. Install the GitHub App and the Atlassian (Jira) app; optionally deploy the Google Docs add-on from the Google Workspace Marketplace.
- Import. In the Threat Modeler, choose Import on the first step and upload the IriusRisk XML file for the project.
- Add evidence in the same step. Attach the current PRD or design doc and connect the application's repository (you can scope to a subfolder and link several repositories). DevArmor merges the imported model with these sources into one view.
How imported data maps:
| IriusRisk data | Arrives in DevArmor as | Next step |
|---|---|---|
| Components, trust zones, data flows | Architecture (components, trust zones and boundaries, data flows) and diagram | Verify in Decompose |
| Assets and data classifications | Data stores and data attributes | Verify in Decompose |
| Threats | Threats with STRIDE category and affected components | Review and approve |
| Countermeasures and their status | Controls | Review status and compliance mappings |
| Custom fields, rules engine logic, test results | Not carried over as fields | Keep the export; capture what matters in Organizational Memory |
Step 4: Verify
- Decompose. Review the architecture DevArmor built from the import plus your documents and code. Where the code shows components or flows the old diagram did not, that is drift you have just found.
- Review. Walk through threats, risks and controls and approve them. Use your exported IriusRisk reports as a checklist: confirm that the critical threats and required countermeasures you tracked are present.
- Save the baseline. Approving creates version 1.0.0. Later changes are compared against it.
Step 5: Put the model to work
- Implement. Push mitigation actions to Jira, generate pen test scopes, and turn automated tests into Code Reviewer policies.
- Design Reviewer. Enable review of new Jira tickets (and Google Docs designs) for the project.
- Code Reviewer and Guardrails. Enable PR review on the project's repositories using Policies, publish AI Guardrails rule files, and roll out the VS Code/Cursor/Kiro extension.
Step 6: Bring over your custom security content
| If you used in IriusRisk | Do this in DevArmor |
|---|---|
| Custom rules | Write each rule's intent as an org policy ("All services that handle cardholder data must…"). Policies apply to every threat model, design review and PR check. |
| Risk pattern libraries | Add your threat and countermeasure patterns and approved designs to Organizational Memory and Secure Building Blocks. |
| Custom standards | Map controls to the matching framework, or bring your control catalog as policy. |
| Questionnaires | Retire them; the Describe step and your design docs capture the same information. |
Step 7: Run in parallel, then switch
Most teams run both platforms side by side for the first wave, compare results, and then move remaining projects in batches. Keep your IriusRisk XML and report exports as the historical record for audits.
Your first 30 days
| Week | Activities | Outcome |
|---|---|---|
| Week 1 | SSO, teams and projects set up. GitHub and Jira connected. First 3 to 5 IriusRisk projects exported and imported. | Priority applications live in DevArmor |
| Week 2 | Verify architecture and approve threats and controls, enriched with current docs and repositories. Custom rules rewritten as policies. | Approved v1.0.0 baselines; drift identified |
| Week 3 | Mitigation actions pushed to Jira. Design Reviewer turned on for priority projects. | Security requirements on every new security-significant ticket |
| Week 4 | Code Reviewer and AI Guardrails enabled on priority repositories. Remaining projects scheduled for migration. | Requirements enforced on every PR and in AI coding agents |
From there, organizational memory makes each new threat model faster, and coverage expands from priority systems to the whole portfolio.
Frequently asked questions
Do we have to redraw our diagrams?
No. Import your IriusRisk projects and DevArmor rebuilds the architecture diagram. Adding current documents and repositories usually makes it more accurate than the original.
Will we lose our history?
Your imported model becomes version 1.0.0 in DevArmor and every later change is versioned. Keep your IriusRisk exports as the record of earlier history.
Our rules engine gives us deterministic results. Is AI output consistent enough?
DevArmor grounds analysis in your architecture, policies and approved patterns, scores risk with a consistent formula, and requires your team to approve architecture, threats and controls before anything is enforced. Every approved version is fixed and comparable.
Do we need to maintain rules?
No. You describe your policies in plain language; there is no rule library to keep up to date.
Do we need code to threat model?
No. DevArmor can build a model from a PRD or design doc alone, so you can threat model systems before they are built.
We use Azure DevOps or ServiceNow, not Jira.
Jira is integrated natively. For other trackers, mitigation actions are available through the REST API and MCP server. Tell us which tracker you use.
Who in our company will use DevArmor?
Security teams in the web app; engineers in Jira, Google Docs, GitHub and VS Code or Cursor; and AI coding agents through rule files and MCP.
How is our data protected?
DevArmor holds SOC 2 Type II, encrypts all customer data in transit and at rest, supports configurable retention, and offers single-tenant and self-hosted options for enterprise customers.
Next steps
- Book a migration session: bring one IriusRisk XML export and a current design doc, and we will import and review it with you live.
- Choose your first-wave applications.
- Read the product documentation at docs.devarmor.com.
Book a migration session with the DevArmor team →
Table of Contents
Subscribe
