Integrating Threat Modelling into Architecture Validation
🌟 Objective
To define how to incorporate threat modelling in a structured way into the technical review and architecture validation process, ensuring that:
- Threat analysis is a mandatory step in technical validation;
- Architecture artefacts include the results of threat modelling;
- There is traceability between architecture, threats and security requirements (Ch. 2).
📁 Artefacts to validate
This process is aligned with the prescriptions of Chapter 4 - Secure Architecture, which defines the minimum artefacts required for technical validation:
| Architecture artefact | Must contain… | Validated by… |
|---|---|---|
| Component Diagram | Trust boundaries, sensitive flows | Architect + Security |
| Technical Solution Document | Summary of threats + mitigation or justification | AppSec / PO / Dev team |
| Release Sheet | Confirmation of the control implemented per threat | Technical owner + QA |
| Exceptions Sheet | Formal justifications for unmitigated risks | Security + Risk Management |
✅ Acceptance criteria for technical validation
| Mandatory item | Source | Verified? |
|---|---|---|
| Complete threat model | DFD, STRIDE, LINDDUN or PASTA | ☐ |
| Threats mapped to Ch. 2 requirements | threats.yaml file or IriusRisk | ☐ |
| Mitigations defined and tested | mitigations.md, backlog, tests | ☐ |
| Accepted risks justified and documented | decisions.md or IriusRisk | ☐ |
| Security participation in the validation | Attendance / review record | ☐ |
🧭 When to apply
| Situation | Validation requirement with threat modelling |
|---|---|
| New critical application | ✅ Mandatory |
| Change to an existing architecture | ✅ Mandatory |
| Integration with external systems | ✅ Mandatory |
| Technical refactoring without functional impact | ⚠️ Recommended (if it affects sensitive flows) |
🔄 Integration with the lifecycle
This process must be articulated with Chapter 6 - Secure Development, ensuring that:
- Architecture validation takes place before development starts (technical gate);
- The threat model is available for review and included as a project deliverable;
- Changes to the system require updating the model and revalidation (automatic trigger);
- The validation status can be made visible in the backlog, ADO, GitHub or the management tool.
✅ Good practices
- Make the threat model a mandatory deliverable in critical projects;
- Use tools that integrate threat modelling and technical documentation (e.g. IriusRisk, PlantUML, Draw.io);
- Ensure that exception decisions are formalised with a justification, an owner and a deadline;
- Include security reviewers in the architecture stages (design review);
- Automate artefact verification and minimum validation as part of CI/CD.
Integrating threat modelling into architecture is not optional in critical contexts - it is an integral part of informed technical decision-making and of security traceability.