Shift-Left with Threat Modelling: A Quick Guide for Startups and SMEs Building Technology

Published by Viet Phan and Raafey Khan, Security Testing and Assurance on 30 April 2025

With the proliferation of cyber attacks and the evolving threat landscape, protecting our systems and data from cybercriminals has become more important than ever before. “Shift-left” security looks to tackle this growing problem and focuses on identifying and mitigating security issues early in the development lifecycle. It also encourages development teams to focus on building secure systems from the very beginning by incorporating security into the system’s design.

The recent Hack Report released by CyberCX for 2025 revealed that application and development security were one of the leading root causes of findings reported by CyberCX’s offensive testers last year, reinforcing the importance for organisations to embed security earlier in the application development lifecycle.

For smaller organisations that may have limited resources and security team members, one of the most effective and low-cost ways to “shift-left” is by implementing threat modelling exercises as part of broader design and sprint planning discussions.

Threat modelling is something every technology team can start doing today, and to some extent you may already be doing it, without using this term. It is something that can be done without deep cyber security experience, as the core focus is on understanding how things should work and what could go wrong.

What is Threat Modelling?

Threat modelling, or sometimes referred to as “evil whiteboarding”, focuses on getting teams to think about what could go wrong and plan mitigations and security controls that are required in the context of the application or system they are building. Often, we use the four-question framework when performing threat modelling:

• What are we building?
• What could go wrong?
• What will we do about it?
• Did we do a good job?

We often see applications riddled with security bugs discovered through penetration testing, which could be identified and addressed earlier in the application design and development phases. Threat modelling can help development teams gain insights into the potential threats to their applications as early as the design phase, enabling more proactive mitigation strategies and decision making, and kickstart the “shift-left” journey.

How to get started:

Get the right people involved

Collaboration between relevant stakeholders is key when it comes to having meaningful threat modelling discussions. For smaller organisations, this may just be a conversation within the development team, but it could very well include solution architects, DevOps, cloud and security teams as your organisation expands. Having a diverse group of people coming together to discuss threats is a good way to incorporate different perspectives and uncover a variety of threats, yielding better outcomes.

Get the whiteboard out

Start modelling your system and drawing a data flow diagram on a whiteboard. This helps establish context and helps you visualise the potential threats and attack pathways to your environment. As you become more comfortable with threat modelling, there are free threat modelling tools such as OWASP Threat Dragon and Microsoft’s Threat Modelling Tool that can be used to help streamline the process.

Start small and scale up

Application systems tend to be complex, making threat modelling a challenge for most organisations. Therefore, it is always good to start small and limit the scope by identifying and focusing on the key assets you want to protect, and understanding the potential threats that could put those key assets at risk. For example, protecting a payroll system or database containing your customers. Once you have achieved a level of comfort with your core assets, it may be time to expand the scope to include other systems using a risk-based approach.

Leverage established frameworks

There are several well-known approaches and frameworks available that can assist with conducting threat modelling in a structured manner. Some of these include STRIDE, DREAD, PASTA, MITRE ATT&CK just to name a few. Leveraging one of these frameworks helps ensure that you have covered all the potential things that could go wrong.

Document and mitigate threats

It’s one thing to talk about threats; it’s another to do something about it. It is essential for threats and countermeasures identified via threat modelling discussions to be recorded and tracked to completion. Ideally, these items should be ingested into existing ticketing or issue tracking systems (e.g. Jira, ServiceNow) so that development teams can triage, prioritise, and action the items in a timely manner. These items can then be used to guide security testing and assurance activities.

Review and update regularly

System and application designs never truly remain the same. There will always be new features and functionality added or design changes that will influence the existing threat models. Therefore, it is important that threat models are regularly reviewed to ensure they are up to date and any new, emerging threats have been captured and addressed accordingly. An approach development teams could take is during each spring planning session, ask the question: does this user story or feature change our threat model? If the answer is yes, update the threat model.

Train development teams

Although you do not need deep technical knowledge or to be a security expert to conduct threat modelling, it certainly helps to understand the common security threats and vulnerabilities that developers may encounter (e.g. OWASP Top 10). Providing dedicated, ongoing security training to development and technology team members may be a medium-to-long term goal for most small-scale organisations.

Define a simple threat modelling process

Threat modelling is meant to be a structured process and should align with your organisation’s development practices whether that be Agile or similar. A well-defined process should include when and how threat modelling activities are performed, who should participate in discussions, how the threat outputs should be interpreted and transformed into actionable items (i.e. countermeasures to implement). For small scale organisations, defining a simple threat modelling approach that outlines when the activity will be done, by who, and how often, is generally sufficient.

CyberCX provides full end-to-end services to support organisations in building and maintaining secure software solutions, including training and support to enable an effective threat modelling program. To learn more, contact us via our website or reach out to Viet Phan or Raafey Khan directly.