I've been tasked with evaluating and potentially standardizing our threat modeling process across several product teams, moving away from disparate spreadsheets and informal whiteboard sessions. IriusRisk is frequently mentioned as a leading enterprise tool in this space, but I'm looking for practical, ground-truth feedback from teams that have gone beyond the pilot phase.
Specifically, I'm interested in understanding the integration and operational realities:
* **Integration into SDLC:** How have you embedded IriusRisk into your existing CI/CD or project management workflows? We use a mix of GitHub Actions and GitLab CI, with Jira for tracking. Was the integration more API-driven, or did you rely on webhooks and manual triggers? Any example of a pipeline step that gates a deployment based on a threat model's status would be invaluable.
* **Customization & Maintenance:** The promise of a centralized, updatable threat library is appealing. However, how much ongoing maintenance does the rule set require? Have you successfully tailored the questionnaire and threat rules to match your specific architectural patterns (e.g., internal Kubernetes deployments, specific cloud provider services, or legacy monoliths)? I'm concerned about the model becoming stale or too generic to be useful.
* **Developer Adoption & Friction:** What was the actual developer experience? Were security teams driving the entire process, or did you manage to get developers to own the creation and updating of threat models? What were the primary points of pushback—time, complexity, tool usability—and how did you mitigate them?
* **Outputs and Downstream Use:** Beyond the obvious reports and dashboards, have you successfully fed the "countermeasures" or "mitigations" from IriusRisk into other systems? For example, automatically creating Jira tickets for security tasks, or exporting a list of required security controls to a Terraform module's validation step? We want the output to be actionable, not just archival.
Our stack is primarily cloud-native (Kubernetes on EKS, various AWS services) with some containerized legacy applications. The goal is to shift security left, but in a way that provides tangible value to development teams rather than being perceived as pure overhead. I'm particularly wary of tools that generate a large volume of low-fidelity findings.
Any insights into the actual time investment per model, the scalability of the approach, or lessons learned from operationalizing IriusRisk would be greatly appreciated. Configuration snippets or workflow descriptions would be especially helpful.
CPU cycles matter
Great question about the SDLC integration. At my previous place we tried connecting it to Jira through their API, but it felt a bit clunky. The sync was one-way, from IriusRisk to create Jira tickets for threats, but updating status back was mostly manual.
For the threat library, we found it needed more tuning than expected, especially for our AWS setup. The generic cloud rules didn't quite fit our use of Lambda and SQS. How often does your team plan to review and update those custom rules? Is that a dedicated role?
CloudNewbie
We've had it in production for about 18 months now. On integration: we settled on a hybrid approach.
We use the IriusRisk API directly in a pipeline stage (GitLab) to check the status of a threat model and fail the build if its 'risk status' is above an agreed threshold. It's not perfect, as sometimes a model is just 'in progress', but it works as a forcing function. The webhook for Jira ticket creation is useful, but we had to build a small middleware service to handle status updates back from Jira, as the native sync wasn't meeting our needs.
For the threat library, be prepared to invest time upfront. The out-of-box rules are a starting point, not a finish line. We have a quarterly review cycle led by our security architects. Without it, the library becomes noisy and teams start to ignore it. Tailoring for specific cloud patterns is mandatory, not optional.