Embedding Threat Modeling into the Product Development Process

The Challenge: Threat Modeling as a One-Off Exercise

In many organisations, threat modeling follows a predictable pattern: a workshop is convened, a document is produced, it ends up in the Confluence space – and is never touched again. Six months later, the product has three new features, two infrastructure components have been swapped out, and the threat model still describes an architecture that no longer exists.

The symptoms are unmistakable: threat models without versioning, missing triggers for updates, and above all an organisational silo between security teams who create the model and engineering teams who make architectural decisions every day. The result is a compliance artefact that can be presented at audits but no longer delivers any operational security value.

The real problem is not a lack of methods or tools, but the structural positioning: threat modeling is treated as a one-off task, not as a continuous design principle. Overcoming this mindset is the first and decisive step.

Fundamentals: What Threat Modeling Really Means in a Product Context

Threat modeling is neither a penetration test nor a classical risk analysis. Whereas a pentest examines existing systems for exploitable vulnerabilities, threat modeling asks – already during design: What could go wrong, and how do we build it so that it doesn’t go wrong?

In a product context, the goal is to systematically identify attack surfaces before they are implemented. Established methods are available for this:

STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) is the most widely used approach for the structured analysis of threat categories at system level.
PASTA (Process for Attack Simulation and Threat Analysis) takes a risk-based, attacker-oriented approach and is particularly suited to complex, business-critical systems.
LINDDUN focuses on privacy threats and is therefore particularly relevant for products processing personal data.

The value of these methods does not unfold in a single workshop. It emerges through repeated application: every design decision, every new data flow diagram, every change to trust boundaries adds new insights. Threat modeling then becomes the shared mental framework of a product team – no longer a special project of the security department.

Structural Anchoring in the SDLC: From Gate Review to Design Principle

Integrating threat modeling into the Software Development Life Cycle (SDLC) requires clearly defined entry points – and equally clearly defined triggers for updates.

Requirements phase: Security-relevant questions should be asked as early as when user stories and system requirements are formulated. “Which actors access this data?” and “Which trust boundaries does this data flow cross?” are not downstream questions – they belong in the Definition of Ready.

Architecture reviews: Every architecture review is a natural point in time to update or validate the threat model. New components, changed integrations or altered deployment topologies change the attack surface – and must be reflected in the model.

Feature iterations: Not every feature requires a full re-modeling, but a lightweight threat modeling check – “What changes in the attack surface as a result of this feature?” – should be part of the standard checklist.

Trigger events for a mandatory update of the threat model should at least include: new external interfaces, changes to authentication or authorisation mechanisms, new data categories, infrastructure migrations, and newly disclosed vulnerabilities in the components used.

Threat Modeling in DevSecOps: Tooling, Automation and Integration

The DevSecOps approach demands that security activities be embedded into the development pipeline as early and as automated as possible. For threat modeling, this means: not every analysis has to be carried out manually by a security expert.

Practically relevant tools include OWASP Threat Dragon (open source, well suited to team-based collaborative modeling), IriusRisk (enterprise-ready, with rule sets for automated threat suggestions) and the Microsoft Threat Modeling Tool (STRIDE-centric, established in Microsoft-oriented environments). These tools support model maintenance but do not replace judgement when assessing context-specific risks.

Particularly promising is the approach taken by the TrustSource platform: here the threat model is not built up manually but synthesised from existing artefacts. Infrastructure-as-Code (IaC) provides the basis for an operationalised bill of materials at infrastructure level (OBOM), architectural descriptions add the structural context, the SBOM provides licence and vulnerability information on the components used, and SAST results in the form of CWEs complete the picture. From this combination the platform feeds a STRIDE analysis – with the effect that the resulting findings are significantly more focused than in generic modeling approaches.

A further advantage: based on this analysis, concrete countermeasures can be proposed that are directly tailored to the identified weaknesses. This makes the results actionable for engineering teams and ideally suited as a basis for discussion in joint security review sessions. Rather than an abstract document, the outcome is a practical working state that can be deepened and further developed within the team. Extremely convenient is the fact that the results are automatically integrated into risk management and therefore do not run the risk of being forgotten on a brown paper in the meeting room.

What automation can deliver: deriving consistent data flow models from existing infrastructure sources, mapping known threat patterns to architectural elements, tracking changes in the model. What imperatively requires human judgement: assessing the likelihood of occurrence and impact potential in the business context, prioritising measures, and deciding on accepted residual risks.

Roles, Responsibilities and Team Enablement

Threat modeling does not work as a single discipline. Who bears responsibility, and who actively contributes?

Security Champions are the key to scaling: developers who act as the link between engineering and security, bring threat modeling into sprint reviews and keep the threat model up to date. They do not need a full security degree – but they do need targeted training, clear methodological references, and organisational backing to be allowed to escalate security concerns.

Architects are responsible for the structural view of the system and are natural owners of the data flow model – the foundation of every STRIDE analysis.

Product owners are responsible for ensuring that security requirements flow into product planning and are not treated as a downstream task. Threat modeling provides them with concrete inputs: which risks exist, which measures should be prioritised.

Practical enablement approaches: structured threat modeling workshops with real product context (no abstract examples), the provision of checklists and threat catalogues as a working basis, and regular retrospectives on completed threat modeling cycles.

Regulatory Tailwind: Requirements from the CRA and Beyond

The EU Cyber Resilience Act (CRA) is fundamentally changing the framework for product security. Manufacturers of products with digital elements are required to ensure cybersecurity throughout the entire lifecycle – and to demonstrate this. Concretely, this means: risk analyses as part of the design process, documentation of security requirements, vulnerability management and structured update processes.

A continuous threat modeling practice not only meets these requirements in substance, it also produces the necessary evidence documents at the same time: versioned threat models as evidence of risk analyses carried out, change logs as proof of continuous review, and structured finding lists as input for vulnerability management.

Anyone who anchors threat modeling as a living process artefact does not create an additional compliance burden – but instead serves reporting obligations as a by-product of a security practice that is worthwhile in any case.

Measuring Success and Continuous Improvement

What is not measured does not improve. This applies particularly to threat modeling, because the benefit is often difficult to see directly.

Suitable metrics include:

Coverage metrics: What proportion of system components and data flows is covered by a current threat model?
Currency ratio: How many trigger events actually resulted in a model update?
Finding-to-fix rate: How many identified threats have been addressed with concrete countermeasures?
Time-to-model: How long does a threat modeling cycle take for a new component – an indicator of process maturity and tool support.

In addition, security incidents should be reviewed retrospectively against the threat model: was the exploited vulnerability captured in the model? If not – why not? This feedback loop is the most effective driver of process improvement.

Conclusion

Three key findings can be noted: First, threat modeling only develops its security value as a continuous process – not as a one-off audit document. Second, the combination of IaC, SBOM and SAST data – as implemented in the TrustSource approach – enables an automated, focused STRIDE analysis that directly enables engineering teams to act. Third, a structurally anchored threat modeling practice delivers, as a by-product, exactly the evidence demanded by the Cyber Resilience Act – making compliance a consequence of good security work rather than a separate burden.