← Years 9–10 Digital Systems

Reviewing and updating a threat model

Checking and updating a threat model whenever the system, its users or the known threats change, for example after a new feature, a new dependency or a new control.

Part of: 9-10 Digital Technologies Vic Curric - Digital Systems and Security — Module 79, VCE Software Development - U4O2 - Cyber Security: secure software development practices — Module 84

Understanding Reviewing and updating a threat model in Years 9–10 Digital Systems

What it does: A new third-party dependency adds new threats, so the threat model is updated to include them. A second person often notices gaps the author missed, so peer review improves the model. A new dependency can bring new vulnerabilities and supply chain risks, so the model needs updating. A new control can lower likelihood or impact. Re-rating shows whether the risk is now acceptable or whether more work is needed. Changes to known threats are a trigger for review. A cosmetic change like button colour does not affect security. Writing the updates down keeps the model accurate and helps others see how and why it changed.

Common mistakes: A new feature changes the system, so the threat model must be reviewed. It should call review_threat_model(), not delete the model. After finding the threats a new dependency brings, we update the threat model. Updating the user manual does not record the new risks. It should be update_threat_model().

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 Reviewing and updating a threat model to a class →

This module's key terms are also in a printable crossword (Modules 70–79) and word search (Modules 41–79).

Take this worksheet further — free with Cloodit

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

Learning
Duo
A school app adds a new feature that lets students upload photos. What should the team do with their threat model?
Leave it alone because it was finished last termReview and update it to cover the new feature
Matches
Model written in Term 1. Next review: never, it is finished.
↓
A threat model is never finished. It must be reviewed whenever the system, users or threats change.
Applying
Meanings
Term
threat model review
Meaning
Checking and updating a threat model whenever the system, its users or the known threats change, for example after a new feature, a new dependency or a new control.
Practice
Review trigger: new feature added
Testing
Gaps
IF newFeature THEN (threatModel)
Check Answer
Spots
1IF new_feature = true THEN
2 delete_threat_model()

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

The 'Space Rabbit' badge — Launch Pad, one of Cloodit's 106 collectible badges
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. A school app adds a new feature that lets students upload photos. What should the team do with their threat model?
A. Review and update it to cover the new feature ✓
B. Leave it alone because it was finished last term
A new feature changes the system, which can add new assets, data flows and threats. The threat model must be reviewed and updated.
2. Which statement about a threat model is true?
A. It is written once and never needs to change
B. It is a living document that is updated when things change ✓
Systems, users and threats keep changing, so a threat model needs regular review to stay useful.
3. Your team starts using a new third-party library in its code. What is the best next step?
A. Add the dependency to the threat model and check for new risks ✓
B. Ignore it because the library was written by someone else
A new dependency can bring new vulnerabilities and supply chain risks, so the model needs updating.
4. A team adds multi-factor authentication to protect logins. What should they do with the risk ratings in the threat model?
A. Re-rate the risks to see how much the control lowered them ✓
B. Keep the old ratings because controls never change risk
A new control can lower likelihood or impact. Re-rating shows whether the risk is now acceptable or whether more work is needed.
5. Which of these is a good reason to review a threat model?
A. The team changed the colour of the app's buttons
B. A new type of attack is reported against similar systems ✓
Changes to known threats are a trigger for review. A cosmetic change like button colour does not affect security.

Match the Pairs

threat model review → Checking and updating a threat model whenever the system, its users or the known threats change
Re-rate: SQLi likelihood High -> Low → Updating a risk rating after a new control, such as input validation, has been added
Adding a new dependency changes the system, so the model must be reviewed for new threats → Change: add payment library -> Review: add supply chain threat
A peer review has someone else check the model for missed threats and wrong ratings → Reviewer: 'You missed a trust boundary at the API'
Model written in Term 1. Next review: never, it is finished. → A threat model is never finished. It must be reviewed whenever the system, users or threats change.
Added MFA to login. Risk ratings left the same. → After adding a control, the risks it affects should be re-rated, because their likelihood or impact may have dropped.

Key Term

threat model review
Checking and updating a threat model whenever the system, its users or the known threats change, for example after a new feature, a new dependency or a new control.

Fill in the Blanks

1. IF newFeature THEN review(threatModel)
Hint: Type the action you take on the threat model when a new feature is added.
2. IF controlAdded THEN rerate(risks) log("risks re-rated")
Hint: Type the keyword that starts a condition, so risks are re-rated only after a control is added.
3. IF systemChanged OR threatsChanged THEN review(threatModel) END IF
Hint: Type the logical operator that triggers a review when either change happens.
4. FOR EACH risk IN threatModel peerCheck(risk) END FOR
Hint: Type the keyword that links each risk to the model being looped through during a peer review.
5. model.version <- model.version + 1
Hint: Type the operator that raises the version number each time the model is updated.

Spot the Error

Question 1
A IF new_feature = true THEN
B delete_threat_model()
C update_risk_ratings()
D END IF
Line B — A new feature changes the system, so the threat model must be reviewed. It should call review_threat_model(), not delete the model.
Question 2
A new_dependency ← true
B IF new_dependency THEN
C list_new_threats()
D update_user_manual()
E END IF
Line D — After finding the threats a new dependency brings, we update the threat model. Updating the user manual does not record the new risks. It should be update_threat_model().
Question 3
A IF control_added = false THEN
B rerate_risks()
C save_model()
D END IF
Line A — Risks should be re-rated when a control HAS been added. The condition should be control_added = true.
Question 4
A model ← load_threat_model()
B reviewer ← get_peer()
C feedback ← author.review(model)
D apply(feedback)
Line C — In a peer review, a different person checks the model. The reviewer should do the review, so it should be reviewer.review(model), not author.review(model).
Question 5
A old ← likelihood * impact
B likelihood ← likelihood + 1
C new ← likelihood * impact
D DISPLAY old, new
Line B — A new control makes an attack less likely, so the likelihood should go down. It should be likelihood - 1, not + 1.

Student with a class code? Join your class →