The Bottleneck That Gets Conveniently Ignored: Why Threat Modeling Usually Stays in the Backlog
Threat modeling is regarded as one of the most effective measures in the security portfolio — and yet, in practice, it remains chronically underused. Not because organisations fail to see its value, but because the effort involved is prohibitively high. A full threat model for a moderately complex system? Two to five days of workshop time, an experienced security architect as facilitator, and in the end a document that will already be outdated six months later.
The outcome is predictable: threat modeling happens when compliance demands it or after a security incident. The rest of the portfolio remains unexamined. In organisations with dozens or hundreds of services, this isn’t the exception — it’s more or less the norm.
The real problem is structural: threat modeling was designed as a manual, expert-driven discipline in an era when software was built more slowly and system landscapes were more manageable. Those underlying assumptions no longer hold today.
The True Cost of Manual Threat Modeling
The high effort is immediately visible as direct cost: workshop hours, preparation, documentation. The hidden costs are even higher: a security architect spending three days on a threat model is unavailable to three other projects during that time. As the team grows, this problem scales at least linearly.
On top of that comes the expertise problem. High-quality threat modeling using STRIDE or PASTA requires a deep understanding of attack vectors, architectural patterns and business context. That combination is rare. Organisations that don’t employ at least one dedicated threat modeling specialist frequently produce results of inconsistent quality — or skip it altogether.
Tip: The EACG threat modeling course is available directly via the TrustSource website and provides a quick, solid entry point.
The third cost factor is opportunity cost in the SDLC. Threats identified during the design phase cost a fraction of what it takes to identify or address them after go-live. This is nothing new, but the implication is rarely followed through consistently: if threat modeling only takes place for 10% of systems, then 90% of the portfolio is systematically under-assessed.
Reproducibility is another underestimated problem. Two teams independently modelling the same system will arrive at different results. The cause isn’t that one team is worse or wrong, but that the process depends heavily on individual assumptions and experience. This makes comparability — and consistent quality across time and teams — difficult.
STRIDE at Scale: What Automation Means in Practice
Automated threat modeling doesn’t mean replacing human judgement. It means systematising the mechanical, time-consuming parts of the process so that security engineers can spend more time on the questions that actually require thinking.
Specifically, the following process steps can be sensibly automated:
Data flow analysis: Data flows and trust boundaries can be extracted from IaC code (Terraform, CloudFormation), architecture diagrams or service meshes. What takes hours manually can, in automated form, produce a structured data flow diagram in minutes.
STRIDE categorisation: Based on identified components and data flows, STRIDE categories can be assigned rule-based. An API gateway without authentication triggers spoofing findings. An unencrypted database connection triggers information disclosure findings. These patterns are formalisable.
Scenario generation: Automated systems can generate plausible threat scenarios from a component model — either rule-based or LLM-supported. The result is not a finished risk assessment, but a structured baseline for human review.
Asset inventory integration: Automated threat modeling only becomes truly scalable when it is connected to the organisation’s asset inventory, so that new services are automatically included in the modeling process.
What continues to require human judgement: assessing business context and impact, prioritising findings, and deciding which risks are accepted. Automation delivers structure; security engineers deliver interpretation.
Example of an automatically generated threat model in TrustSource, using IaC, architecture, SBOM, vulnerability and SAST information
Automated Threat Modeling in the DevSecOps Pipeline
The technical integration follows a clear pattern: threat modeling must be tied to those points in the development process where security-relevant changes occur.
Trigger mechanisms: Architectural changes — new services, altered data flows, new external integrations — should automatically trigger a threat model update. This can happen via IaC changes in pull requests or via dedicated architecture-as-code definitions.
Pull request integration: Findings from the threat modeling process can be embedded directly as PR comments or checks in the review process. This shifts security feedback to where developers are already working.
Jira integration: Identified threats are created as structured tickets with severity, STRIDE category and a link to the threat model — not as informal security findings, but as prioritisable backlog items.
Vulnerability management integration: Threat modeling findings can serve as context for existing vulnerability management processes — particularly to distinguish which CVEs are actually relevant in which threat context.
The transition into risk management requires a defined escalation path: which findings are handled directly by the team? Which require a security review? Automation makes these thresholds both surmountable and enforceable.
Automation Approaches Compared
Not all automation approaches are equivalent. A pragmatic assessment:
Rule-based template engines are the lowest-barrier entry option. They offer high consistency and low false-positive rates for known architectural patterns, but quickly reach their limits with complex or unusual systems. Maintaining the rule library is labour-intensive.
Graph-based modeling represents system architectures as graphs and enables traversal-based analysis of attack paths. This approach scales well and is well auditable, but requires initial investment in data model and integration.
LLM-supported analysis offers the highest flexibility and can generate plausible threat scenarios even from unstructured architectural descriptions. The challenges lie in consistency, a tendency toward false positives, and the difficulty of auditing results. LLMs are suitable as a foundation, but not as the sole analysis mechanism.
For most organisations, a hybrid model is recommended: rule-based baseline analysis for high consistency, LLM support for scenario generation and contextualisation, human review for final assessment.
From Security Gatekeeping to Security Enablement
Scaled threat modeling fundamentally changes the role of security teams. The classical model — security reviews, product engineering implements — no longer works with a hundred parallel product developments.
The new model: security engineers define the structure, methodology and quality criteria. Product teams carry out the threat modeling, supported by automation and clear guidelines. Security engineers review results and escalate findings instead of performing every process step themselves.
This shift requires cultural investment: training, clear responsibilities and tooling that doesn’t overwhelm product teams. It pays off in the form of ownership: teams that have developed their own threat model are more motivated to actually address the risks identified.
Threat Model Coverage as a KPI makes this shift measurable: what proportion of the service portfolio has an up-to-date threat model? This metric can be integrated into security scorecards and OKR processes and creates transparency about the actual coverage level.
A Pragmatic Start: Step by Step Towards Scale
No threat modeling programme scales overnight. The pragmatic path leads through defined pilot projects:
-
Assess maturity: Is there a documented threat modeling process? Are results consistently captured? What is the current coverage? This inventory defines the starting point.
-
Select a pilot project: A team with strong security affinity, a well-documented system, a manageable scope. Introduce automation tools, iterate the process, document learnings.
-
Evaluate tooling: Assess existing options — from Microsoft Threat Modeling Tool through OWASP Threat Dragon to commercial platforms like TrustSource — primarily for their ability to integrate into the existing pipeline, not primarily for feature completeness.
-
Expand coverage incrementally: Extend from the pilot to further teams and systems. Automation allows the effort per threat model to be reduced. The point isn’t to skip the process step, but to lay the foundation for engaging with it.
-
Don’t wait for tool maturity: Any threat model created today with incomplete automation is better than none. Perfection is the enemy of progress, especially in the early scaling phase.
Conclusion
Three key takeaways this article makes the case for:
- Automation makes threat modeling economically scalable. Manual effort has been the biggest inhibitor to date — not a lack of awareness or missing methodology.
- STRIDE and structured automation complement each other. Agents can take on the bulk of the mechanical analysis work; human judgement remains indispensable for prioritisation and contextualisation.
- Cultural change is just as important as tooling. Scaled threat modeling requires product teams to take on security ownership — and security teams to provide the infrastructure that makes this possible.