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
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
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?