Milestone map
Milestone map
3 milestones
Study Secure Design Principles and Threat Modelling
6–12 weeks
Study core secure software design principles: least privilege, defence in depth, fail secure, complete mediation, and separation of duties. Study the STRIDE threat model. Apply STRIDE to an existing codebase or system you have access to: produce a threat model document identifying at least eight threats (at least one per STRIDE category) with likelihood and impact ratings.
Proof required
Submit: a threat model document (at least 600 words) applying STRIDE to a specific system you have access to, with at least eight identified threats (at least one per STRIDE category), each with: the specific attack scenario, affected component, likelihood rating (1–5), impact rating (1–5), and an initial mitigation suggestion; and evidence the system is one you have access to. A security practitioner, software architect, or CS lecturer with security experience must confirm the threat model is accurate.
What gets checked
- At least eight threats identified — at least one for each STRIDE category (Spoofing, Tampering, Repudiation, Information Disclosure, DoS, Elevation of Privilege)
- Each threat includes a specific attack scenario — not just the category name
- A security practitioner has confirmed the threat model is accurate
Common mistakes
- Threat model entries that name the STRIDE category without describing the specific attack scenario
- Applying STRIDE to a hypothetical system rather than a system you have access to
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Are at least eight threats identified — at least one per STRIDE category?
- Does each threat describe a specific attack scenario — not just the category name?
- Ask: 'which threat in your model has the highest combined risk score, and what makes it higher than the others?' — tests understanding of risk prioritisation
You'll sign in first, then come straight back here.
Implement Mitigations and Verify Against the Threat Model
8–14 weeks (after milestone 1)
For the three highest-risk threats in your threat model, implement the mitigations in working code. For each mitigation: explain what security property it enforces, write a test that passes WITH the mitigation and fails WITHOUT it, and document in an Architecture Decision Record why you chose this mitigation over alternatives.
Proof required
Submit: a public GitHub repository containing the three mitigation implementations with test output showing passing WITH mitigation and failing WITHOUT mitigation; and three ADRs (one per mitigation) documenting the chosen mitigation, alternatives considered, and the rationale. A security practitioner or software engineer with security experience must confirm the mitigations actually address the identified threats.
What gets checked
- Test output shows both passing WITH and failing WITHOUT mitigation — both cases documented
- Each ADR specifies at least one alternative mitigation that was considered and rejected
- A security practitioner has confirmed the mitigations actually address the identified threats
Common mistakes
- Tests that only verify the mitigation works without demonstrating failure when the mitigation is removed
- ADRs that describe the mitigation without documenting alternatives that were considered
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Do tests show both passing WITH and failing WITHOUT mitigation?
- Does each ADR document at least one alternative mitigation that was rejected?
- Ask: 'what security property does your first mitigation enforce, and why is that property sufficient to address the threat?' — tests depth of understanding
You'll sign in first, then come straight back here.
Present the Secure Design in a Security Review
4–8 weeks (after milestone 2)
Write a complete secure design document: updated threat model, implemented mitigations with test evidence, remaining risk register, and operational security considerations (what to log, what to alert on). Present to a security practitioner who challenges the threat model's completeness and at least two mitigation choices.
Proof required
Submit: a complete secure design document (at least 1,000 words) with updated threat model, mitigation evidence linking to the repository, remaining risk register with acceptance rationale, and operational security considerations; and a recording or transcript of a security review with a practitioner who challenged the threat model's completeness and at least two mitigation choices.
What gets checked
- Remaining risk register acknowledges unmitigated threats and explains the risk acceptance rationale
- Operational security section specifies which events to log and which events should trigger an alert
- A security practitioner challenged the threat model's completeness and at least two mitigations in the documented review
Common mistakes
- Risk register that only lists mitigated threats without acknowledging remaining risks
- Operational security section that describes monitoring generally without specifying what events to log or alert on
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Does the risk register acknowledge remaining risks with acceptance rationale?
- Does the operational security section specify specific events to log and alert on?
- Were the threat model's completeness and at least two mitigations challenged in the documented review?
You'll sign in first, then come straight back here.