Project: a one-page threat model for your own system

The previous forty-four lessons taught you to recognise and fix bug classes. This one differs in kind: it teaches nothing new, it asks you to produce something usable at work.

That is why it is a project rather than a challenge. A challenge has an answer you can compare against; a project has an artefact whose value lies in applying to your own system — and nobody but you can verify that.

What to produce: a one-page threat model for a real feature in your project.

Three criteria for choosing the feature, and the third is the important one:

1. It is being designed, or coding just started. Threat modeling after the code exists turns every finding into a refactor rather than a decision — as stride-in-practice argued.
2. It touches money, permissions, or several customers' data. A feature that changes a UI colour has nothing to threat model.
3. You are the person who will write its code. This criterion decides the value: abuse-cases argued that for business-logic bugs the person building the feature is the best finder, being the only one who knows which behaviour is correct for the business.

Rubric — six criteria, and 5 and 6 are what separate a good threat model:

Criterion 6 is the path's final one and the most worth carrying: every fix step in the previous forty-four lessons ended with the question "what does this patch not stop". That is not a presentational convention — it is a skill a tech lead recognises in somebody immediately, and it is what separates a usable security report from one that produces a feeling of safety.