IriusRisk Alternative: DevArmor vs ThreatModeler Integrations

TL;DR

• IriusRisk is now part of ThreatModeler. Existing customers can enter the combined ThreatModeler ecosystem or switch to DevArmor.
• DevArmor fits teams that need continuous threat modeling and Policy-as-Code controls that can block unsafe pull-request merges.
• DevArmor supports agentic development through living security context shared with developers and coding agents in Cursor, VS Code, and MCP workflows.
• ThreatModeler offers a broader, more mature enterprise integration ecosystem, including GitHub, IDE, cloud, and infrastructure-as-code support.
• ThreatModeler better suits organizations that prioritize broad compliance-standard coverage and audit-ready reporting. DevArmor leads for earlier enforcement and AI-assisted development.

What the IriusRisk–ThreatModeler merger means for existing customers

ThreatModeler announced its acquisition of IriusRisk on January 8, 2026. Invictus Growth Partners holds a majority stake in the combined company, while Paladin Capital Group remains a shareholder. ThreatModeler CEO Matt Jones leads the company, and IriusRisk CEO Stephen de Vries joined the combined leadership structure.

The acquisition consolidates ownership, but the available material does not describe a completed product merger. ThreatModeler Nexus and the IriusRisk Threat Modeling Tool still operate under separate brands and websites. IriusRisk also continues to document its own integration catalog, including Jira, Jenkins, GitHub Actions, Azure DevOps, Terraform, and CloudFormation.

ThreatModeler has not published a clear timeline for one unified platform in the supplied sources. The sources also leave open how existing IriusRisk integrations, threat models, reporting workflows, and custom API work will move into a combined product. Customers should verify those migration details before treating corporate consolidation as technical continuity.

Existing IriusRisk customers therefore have two practical paths. They can remain within the combined ThreatModeler ecosystem and retain access to its mature enterprise integrations and compliance reporting. Alternatively, they can evaluate DevArmor for pull-request-stage Policy-as-Code enforcement, shared security context for developers and coding agents, and traceability between implementation reviews and approved design decisions.

Comparison at a glance: ThreatModeler/IriusRisk vs. DevArmor

ThreatModeler acquired IriusRisk in January 2026, but the available materials still describe separate branded products and do not provide a unified migration timeline. Existing customers should compare the combined ecosystem with DevArmor based on where reviews start, what records return to development tools, and whether a failed control can stop code.

CI/CD pipeline triggers: where each review starts and stops

ThreatModeler/IriusRisk can start reviews at several pipeline points, but each integration provides a different level of control. Jenkins can gate promotion until code meets compliance requirements. GitHub Actions can call the IriusRisk API to retrieve data and run custom automation, while Azure DevOps supports bidirectional workflows. The GitHub path depends on pipeline scripts, and the public documentation does not confirm a packaged status check that automatically blocks an unsafe pull-request merge.

A gate becomes blocking enforcement only when the pipeline prevents the next action without human approval. Jenkins can provide that control when promotion depends on a passing result. By contrast, an API response or ticket that informs a reviewer remains advisory unless you connect it to a required check. Azure DevOps can exchange updates with ThreatModeler/IriusRisk, but its published description does not specify which findings trigger an automatic failure.

DevArmor starts enforcement at the pull request. Its Policy-as-Code control evaluates proposed changes against approved security decisions and can block a merge when the code violates policy. DevArmor also preserves traceability between the implementation review and the design decision or threat model that produced the requirement. Developers receive the decision where they review code rather than translating a separate report into a merge decision.

Pull-request enforcement follows a shift-left model because it stops unsafe code before integration. Shield-right controls operate later through deployment or runtime enforcement and monitoring. Security research distinguishes these control points, and neither vendor’s cited integration documentation establishes runtime enforcement here. ThreatModeler/IriusRisk offers configurable pipeline gating across a mature toolchain. DevArmor provides the clearer documented path for automatic prevention at the pull-request boundary.

Jira and ticketing: write-back behavior and workflow depth

ThreatModeler/IriusRisk supports two-way ticket workflows with Jira, CA Rally, and ServiceNow. The IriusRisk integration documentation says users can manage work through either the threat-modeling interface or Jira. Security staff can create and track remediation work without requiring developers to operate inside IriusRisk for every update.

Public documentation does not define every field or status synchronized between the platforms. It also does not connect Jira ticket status to a pull-request check that automatically prevents a merge. You should therefore verify field mapping, ownership rules, synchronization behavior, and pipeline gating during migration planning. A two-way ticket exchange can keep remediation records current, but a developer or security reviewer may still need to decide whether the code can proceed.

DevArmor uses Jira as part of a traceable review chain. An implementation review can refer back to the approved design decision or threat model that governs the change. The Jira item therefore carries context about the applicable security decision rather than serving only as an isolated finding for someone to triage.

DevArmor can pair that traceability with Policy-as-Code checks in the source-control workflow. Jira records the work and its design basis, while the pull-request control can block an unsafe merge. Existing IriusRisk customers should compare both layers separately. Ticket synchronization determines how people assign and close work. Merge enforcement determines whether unresolved policy failures can enter the codebase.

GitHub and source code management integrations

ThreatModeler/IriusRisk connects GitHub through an API-driven GitHub Actions model. A workflow can run on a push or pull request, call the platform API, and use returned data in later automation. The published integration description does not confirm a native GitHub app, a standard pull-request comment format, or an automatic merge block. You must configure the workflow and decide how its result affects the pipeline.

DevArmor places security review directly in the pull-request lifecycle. Its native GitHub and source code management integrations evaluate changes against Policy-as-Code, write the review result into the pull-request workflow, and can block an unsafe merge. The control therefore acts before code enters the protected branch instead of relying on a developer to interpret an advisory result.

DevArmor also extends security context into VS Code, Cursor, and MCP-connected tools. Developers and coding agents can consult approved design decisions while producing code, then carry that context into the pull-request review. The implementation review remains traceable to the threat model or design decision that authorized the approach.

The practical difference concerns how much configuration separates a review from enforcement. ThreatModeler/IriusRisk provides flexible GitHub Actions and API building blocks, which suit organizations prepared to construct their own checks and write-back behavior. DevArmor provides an IDE-to-pull-request path with an explicit blocking control, which better fits teams that want the same security context to guide both human developers and coding agents.

Cloud and IaC workflows: Terraform, Kubernetes, and serverless

ThreatModeler/IriusRisk provides a verified direct import path for AWS environments, but its documented coverage remains narrow. The AWS import feature is in beta and may not work in every region. Its first release imports a limited set of resources, including VPC networking, EC2, and RDS.

The combined offering also supports Terraform and CloudFormation through Open API mapping. However, public documentation does not establish whether an IaC commit automatically triggers a review or writes findings back to a pull request. It also does not confirm blocking controls for IaC changes. Comparable details remain undocumented for Kubernetes manifests, serverless configurations, and direct Azure or Google Cloud imports. Documentation gaps do not prove that support is absent, but buyers should verify those workflows during evaluation.

DevArmor approaches infrastructure changes through continuous design review and living security context. Approved architecture decisions can inform later implementation reviews, and Policy-as-Code can block unsafe pull-request merges. That model can detect divergence between an approved infrastructure design and its implementation before deployment.

DevArmor's public materials do not verify native parsers for Terraform plans, Kubernetes manifests, or serverless templates. They also do not confirm provider-specific cloud imports. Buyers should therefore treat DevArmor's advantage as continuous governance around infrastructure changes rather than assume broad native IaC ingestion. A proof of concept should test the exact repository trigger, review output, merge control, and cloud resource coverage you require.

Policy enforcement and agentic development readiness

AI-assisted coding increases the number and speed of proposed changes, which makes periodic threat model reviews easier to outpace. A coding agent can produce an implementation before a security architect reviews the underlying design. Late-stage scanning may detect a violation after the code already exists, but it cannot give the agent the approved security constraints while the agent writes that code.

DevArmor keeps security context available to developers and coding agents through integrations such as GitHub, VS Code, Cursor, and MCP. Approved threat models and design decisions inform implementation reviews. Traceability then lets a reviewer connect a code finding to the design decision or control that caused it, which provides both the required correction and its rationale.

Policy-as-Code turns those decisions into enforceable pull request checks. When a change violates a configured policy, DevArmor can block the merge instead of relying on a ticket or advisory finding. Security architects retain control over the policy, while developers and agents receive feedback within the workflow where they make the change.

The combined ThreatModeler/IriusRisk offering brings a broader, more established integration ecosystem. Its GitHub and IDE connections, cloud and IaC automation, and audit-ready compliance reporting may suit organizations with mature governance programs and extensive reporting obligations. Available information does not establish the same depth of agent-shared context or pull-request blocking that DevArmor provides.

DevArmor therefore fits teams that want security decisions to guide AI-generated code and govern every pull request. ThreatModeler/IriusRisk remains a credible choice when ecosystem breadth and established compliance workflows carry more weight than agent-level context and merge enforcement.

Best for: matching the platform to the team

• Best for existing IriusRisk customers seeking a modern alternative. DevArmor fits customers who want continuous threat modeling tied to implementation. Traceability links code reviews to approved design decisions, so security context stays current as software changes.

• Best for pull-request-stage enforcement. DevArmor applies Policy-as-Code to pull requests and can block merges that violate approved security controls. Automated blocking suits teams that need enforceable guardrails rather than findings that require a person to stop a release.

• Best for agentic development. DevArmor supports Cursor, VS Code, and MCP workflows. Developers and coding agents receive shared security context inside their working environment, which lets them apply design decisions before generated code reaches review.

• Best for broad compliance-standard reporting. ThreatModeler/IriusRisk fits organizations that prioritize established enterprise reporting and a mature integration catalog. Its documented ecosystem includes Jira, ServiceNow, Jenkins, Azure DevOps, Terraform, and CloudFormation, while its compliance workflows produce audit-ready reports across multiple standards.

Migration recommendation for IriusRisk customers

Choose the combined ThreatModeler offering if your security program depends on a mature enterprise integration ecosystem and broad, audit-ready compliance reporting. Existing IriusRisk customers may also reduce migration disruption by remaining within the combined product portfolio. Before committing, confirm how current models, reports, integrations, and governance workflows will carry into the consolidated offering.

Evaluate DevArmor if you need security controls to operate at the pull request stage or expect AI coding agents to take a larger role in development. DevArmor can apply Policy-as-Code to every pull request, block unsafe merges, and connect implementation reviews to approved design decisions. Its shared security context also gives developers and coding agents the same current guidance inside GitHub, VS Code, Cursor, and MCP workflows.

Your required enforcement point should determine the choice. ThreatModeler supports established threat modeling and compliance governance across the enterprise. DevArmor fits teams that want approved security decisions enforced continuously before code merges, including code produced with AI assistance.