← VCE Software Development U4O2

What threat modelling is

A structured way to work out what could go wrong with a system, before and during development, so risks are found, fixed and confirmed early and then reviewed again.

Part of: VCE Software Development - U4O2 - Cyber Security: secure software development practices — Module 71, ACARA Digital Technologies Years 9–10 — Cyber Security Threats and Vulnerabilities — Module 44, WA Computer Science ATAR Year 11 — Cyber Security — Module 135

Understanding What threat modelling is in VCE Software Development U4O2

What it does: Early and repeated is a key feature of threat modelling. The model is revisited when the system changes, rather than done once and forgotten. Different people see different risks, so a mix of roles takes part in threat modelling. It is not left to one person. You must understand the system first, then find and treat threats, and finally check that the fixes worked. Define sets the scope: the system, its parts, its data and its assets. Patching is a mitigation done later. A planned control is not proof. Confirming means testing or reviewing to show the threat is really dealt with.

Common mistakes: The first stage of threat modelling is to define the system (its scope, assets and data flows), not to release it. Line 1 should be stage1 = 'define the system'. The stages run in order: define, identify and mitigate, then confirm. Confirming before any threats have been identified makes no sense. Line 2 should be identify(system).

Class: _____________________ · Name: _____________________ · Date: _________

Free printable worksheet with full answer key — or add this module to a class and your students practise it interactively.

🖨 Print worksheet + answer key Add What threat modelling is to a class →

This module's key terms are also in a printable crossword (Modules 49–72) and word search (Modules 49–130).

Take this worksheet further — free with Cloodit

Each concept is reinforced from every angle — learned, then applied, then tested.

Learning

Duo

Which describes threat modelling best?

A structured way to work out what could go wrong with a system so risks can be dealt with earlyWriting code that attacks a competitor's system to see if it breaks

Matches

Run threat modelling once after the software is released, then never again

↓

Threat modelling should be done early, before and during development, and repeated as the system changes. Doing it once after release finds problems too late and the model goes out of date.

Applying

Meanings

Term

threat modelling

Meaning

A structured way to work out what could go wrong with a system, before and during development, so risks are found, fixed and confirmed early and then reviewed again.

Practice

STAGE 1 DEFINE the system and its assets

Testing

Gaps

STAGE 1 = the system and its assets

Check Answer

Spots

1stage1 = 'release the system'

2stage2 = 'identify, mitigate'

Cloodit turns curriculum-aligned coding content into journeys students work through one biome at a time.

Students earn collectable badges

Over 100 of them, across seven natural biomes.

Study Buddy

Students build a real study resource

Turns their work into revision material ready for Flash Cards and Exam study.

Diamond Dash — one of Cloodit's live, competitive Sprint games

Students lock in with Sprints

Live, competitive practice for the start of the lesson or a teacher-led lesson finisher.

A Cloodit certificate of achievement, ready to personalise and print

Custom printable certificates

Honour your top performers, or encourage a student who's trying hard — ready to print in seconds.

Add to class →

Quick Questions

1. Which describes threat modelling best?

A. A structured way to work out what could go wrong with a system so risks can be dealt with early ✓

B. Writing code that attacks a competitor's system to see if it breaks

Threat modelling is a structured, planned activity to find and deal with risks. It is not an attack on anyone.

2. When is the best time to start threat modelling?

A. Early, during planning and design, then repeated during development ✓

B. Only after the software has been released to users

Fixing problems early is cheaper and safer. The model is then revisited as the system changes.

3. Which is the correct order of the three stages of threat modelling?

A. Define the system, identify and mitigate threats, confirm the threats are mitigated ✓

B. Confirm the threats are mitigated, define the system, identify and mitigate threats

You must understand the system first, then find and treat threats, and finally check that the fixes worked.

4. What happens in the 'define' stage?

A. Install patches and delete old user accounts

B. Work out what the system is, what it does and what needs protecting ✓

Define sets the scope: the system, its parts, its data and its assets. Patching is a mitigation done later.

5. What happens in the 'confirm' stage?

A. Assume the threats are fixed because a control was planned

B. Check that each threat has actually been mitigated, for example by testing ✓

A planned control is not proof. Confirming means testing or reviewing to show the threat is really dealt with.

Match the Pairs

threat modelling → A structured way to work out what could go wrong with a system, before and during development, so risks can be dealt with early

Define → Identify and mitigate → Confirm → The three stages of threat modelling: describe the system, find threats and plan controls, then check the threats are actually dealt with

Threat modelling is done early and repeated, so it is reviewed whenever the design or the threats change → Review threat model: every sprint or design change

Threat modelling involves more than one role, such as developers, testers, security staff and the client → Participants: developers, testers, security, client

Run threat modelling once after the software is released, then never again → Threat modelling should be done early, before and during development, and repeated as the system changes. Doing it once after release finds problems too late and the model goes out of date.

Threat model stages: Define → Identify and mitigate → Release (no confirm step) → The final stage is confirm, not release. Without confirming, nobody knows whether the mitigations actually deal with the threats.

Key Term

threat modelling

A structured way to work out what could go wrong with a system, before and during development, so risks are found, fixed and confirmed early and then reviewed again.

Fill in the Blanks

1. STAGE 1 = DEFINE the system and its assets

Hint: Type the name of the first stage, where you describe the system being modelled.

2. STAGE 2 = IDENTIFY threats and mitigate them

Hint: Type the name of the second stage, where you find what could go wrong.

3. STAGE 3 = CONFIRM threats are mitigated

Hint: Type the verb for the final stage, which checks the fixes actually worked.

4. WHEN: early in design, then repeat often

Hint: Type the word for when threat modelling should begin, so risks are dealt with sooner rather than later.

5. WHO: developers, testers and security staff

Hint: Type the kind of specialist who joins developers and testers in the threat modelling team.

Spot the Error

Question 1

A stage1 = 'release the system'

B stage2 = 'identify, mitigate'

C stage3 = 'confirm fixes work'

Line A — The first stage of threat modelling is to define the system (its scope, assets and data flows), not to release it. Line 1 should be stage1 = 'define the system'.

Question 2

A define(system)

B confirm(system)

C mitigate(system)

D confirm(system)

Line B — The stages run in order: define, identify and mitigate, then confirm. Confirming before any threats have been identified makes no sense. Line 2 should be identify(system).

Question 3

A define(system)

B threats = identify(system)

C ignore(threats)

D confirm(threats)

Line C — Threat modelling does not stop at finding threats. Each identified threat must be mitigated. Line 3 should be mitigate(threats).

Question 4

A if system_in_development:

B review_threat_model()

C update_controls()

Line A — A threat model is repeated while the system changes, so it needs a loop. An if statement would only review it once. Line 1 should be while system_in_development:.

Question 5

A phase = 'design'

B if phase == 'design':

C threat_model('early')

D cost_to_fix = 'high'

Line D — Threats found early, during design, are cheaper and easier to fix than threats found after release. Line 4 should set cost_to_fix to 'low'.

Student with a class code? Join your class →