Threat Modelling: How to Identify Security Risks Before You Write a Line of Code

Security findings that come out of a pen test late in a development cycle tend to fall into two categories. The first is implementation flaws: specific code that was written incorrectly and can be fixed with targeted changes. The second is architectural issues: decisions made early in the design phase that are now baked into the system and expensive to change. The first category is annoying. The second category is the one that costs significant time and money to remediate, and the one that threat modelling is specifically designed to prevent.

Threat modelling is not a workshop for enterprise security teams with days to spend on documentation. It is a structured conversation that asks the right questions before a system is built. A 90-minute session at the design stage can surface the exact issues that would otherwise appear as high-severity architectural findings in a pen test report six months later. The cost of fixing an issue in design is a fraction of the cost of fixing it in production.

What STRIDE Gives You

STRIDE is a threat modelling framework that provides a checklist of threat categories to consider for any system component. The acronym covers Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. The value of the framework is not that it is comprehensive or theoretically complete. It is that it gives a development team a structured way to ask "what could go wrong here?" without relying on whoever in the room happens to have security knowledge to remember every possible attack type.

Working through STRIDE for a system component means asking: can an attacker pretend to be something they are not (Spoofing), can they modify data in transit or at rest (Tampering), can they deny having taken an action because there is no audit trail (Repudiation), can they access data they should not (Information Disclosure), can they make the system unavailable (Denial of Service), can they gain permissions they should not have (Elevation of Privilege). For each component and each threat category, the question is whether a control exists. If not, the conversation is about whether to add one or accept the risk.

Running a Practical Threat Model Session

A practical threat model session for a small team starts with a data flow diagram. This does not need to be formal. A whiteboard or a shared drawing tool showing the components of the system, what data flows between them, and where trust boundaries exist is sufficient. The trust boundaries are the most important part: they are the lines where a request crosses from one context of trust to another, such as from a public user to an application server, or from an application server to a database. Vulnerabilities tend to cluster at trust boundaries.

Work through the diagram component by component using STRIDE. For each identified threat, record whether a control exists and what it is, or record the decision to accept the risk and who made that decision. The output of the session does not need to be a formal document. A shared note with a list of identified threats and their associated controls or risk decisions is enough. The goal is a record that can be referenced during implementation, not a complete risk register.

What a Threat Model Catches That a Pen Test Does Not

Pen tests are excellent at finding implementation flaws and known vulnerability patterns. They are less effective at finding design decisions that are inherently insecure, because by the time a pen test runs, those decisions are embedded in the system. A threat model catches design decisions: choices about where authentication is enforced, how data is segmented between tenants, whether audit logging exists, and how privilege separation is structured. These are decisions that can be changed cheaply before code is written and expensively after.

A practical example: an architecture that places sensitive data in a shared cache without per-tenant isolation might pass a basic pen test if the tester does not have visibility into the caching layer. A threat model that asks "what happens to this data in the caching layer, and who can access it?" surfaces the issue before it is built. This is the category of finding that shows up repeatedly in pen test reports for applications that have never had a formal design review.

Making Threat Modelling a Regular Practice

For a 20-person engineering team, threat modelling does not need to happen for every change, but it should happen for every significant feature or architectural decision. A useful trigger is any change that introduces new data flows, new external integrations, new trust boundaries, or new authentication or authorisation logic. These are the changes most likely to introduce design-level security issues.

The biggest obstacle to making threat modelling a regular practice is the perception that it requires security expertise to run. It does not. It requires someone who can facilitate a structured conversation and a team that understands the system being designed. The STRIDE framework is the structure. If a team is starting from scratch, having a security practitioner present for the first two or three sessions is useful to calibrate what level of analysis is appropriate, but the goal is a practice that the team can run independently.

• Draw a data flow diagram before starting, focusing on trust boundaries
• Work through STRIDE for each component at each trust boundary
• Record identified threats, controls, and explicit risk decisions
• Trigger a threat model for any change that introduces new data flows or integrations
• Aim for 60 to 90 minutes per feature, not a multi-day workshop

We run threat modelling sessions for engineering teams and can help calibrate the process to your team's size and cadence. Reach us at info@cyberlinx.com.au.