Chapter 50 — Final defense
Lesson map
Lesson 50 published. Map, example, EX148.
flowchart TD
N0["Learning outcomes"]
N1["50.1 Presentation"]
N2["50.2 Technical questions"]
N3["50.3 Ethical questions"]
N4["50.4 Reflection"]
N5["50.5 Development"]
N6["50.6 Thanks"]
N7["Preparing the defense"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX148"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["50.1 Presentation"]
N2["50.2 Technical questions"]
N3["50.3 Ethical questions"]
N4["50.4 Reflection"]
N5["50.5 Development"]
N6["50.6 Thanks"]
N7["Preparing the defense"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX148"]
[Learning outcomes]
|
v
[50.1 Presentation]
|
v
[50.2 Technical questions]
|
v
[50.3 Ethical questions]
|
v
[50.4 Reflection]
|
v
[50.5 Development]
|
v
[50.6 Thanks]
|
v
[Preparing the defense]
|
v
[Worked example] --> [Exercise EX148]
Learning outcomes
You will (1) present and defend the capstone and thesis; (2) answer technical and ethical questions; (3) reflect on the five-year journey; (4) plan continued professional development.
50.1 Presentation
Twenty-five minutes: the original incidents, requirements, design, results, trial, limits and future work.
Starting with the original incidents reminds examiners why the work matters. The middle part moves quickly through requirements and design to the results, where most attention belongs. Limits and future work come before questions, so examiners see that Kwame knows what the verifier cannot do. He leaves time for questions rather than filling every minute with slides. A single results slide shows the five detected mismatches and timings.
50.2 Technical questions
"What if an attacker compromises your CI provider?" Kwame explains that provenance would then be untrustworthy and reproducible builds or a second independent builder would be needed. "Why not verify every file on riders' phones?" He explains privacy and battery costs, and that store-level checks catch tampering before installation.
Both answers show he understands the boundaries of his design. The first admits a real weakness and names a remedy instead of defending the design at all costs. The second explains a choice in terms of riders' interests, privacy and battery life, and shows that the chosen check sits at a point where it still catches the threat. Examiners look for this kind of reasoning more than for perfect designs.
50.3 Ethical questions
"Could the verifier's data reveal riders?" No: it handles only app releases, not rider data.
Kwame explains the answer further: the verifier reads release files and build records from the store and Coastline's systems, and it never touches riders' phones or accounts. Logs record releases and check results only. He adds that the verifier could still affect riders indirectly, for example if a false alert delayed a needed security update, which is why the false alert rate was a success measure. Examiners also ask about disclosure, and he describes how a real mismatch would be reported through Coastline's incident process.
50.4 Reflection
From calculus models of exposure to a deployed verifier, Kwame sees supply-chain security as an engineering discipline of requirements, design, measurement and verification.
Looking back, he notices how the first-year incidents shaped every later step. The template advisory led to SBOMs and advisory checks; the mirror mismatch led to digests, signing and provenance. Mathematics and physics courses that once seemed distant gave him ways to model exposure and reason about corruption. He ends with the view that controls are only as good as the evidence that they work.
50.5 Development
He plans a professional certification and joins an open-source supply-chain security working group.
A certification gives a structured way to keep his knowledge current and shows employers what he knows. The working group connects him with engineers who face similar problems in other organisations and lets him contribute to shared tools and standards. He also plans to keep reading new research, since attack classes and defences change quickly. Ingrid agrees to remain an informal mentor, meeting him monthly to review his goals.
50.6 Thanks
Ingrid and the Coastline team receive the final dossier and verifier.
The handover is a way of saying thanks in practice, since the work stays with the organisation that supported it. Kwame also thanks his tutor, the reviewers and his classmates who played examiners. He notes in his thesis acknowledgements that the external reviewer's suggestion changed his future work. Coastline's leadership thanks the platform team for hosting him, and the verifier is listed as a team project in the next annual security review, with Kwame named as its original author.
Preparing the defense
Kwame rehearses three times with classmates who play examiners. He prepares short backup slides on the threat model, test set and failure trial. He practises answering in under a minute, then offering more detail if asked. Rehearsal helps him stay calm and clear, especially on questions about what the verifier cannot do.
Handover
After the defense, Kwame hands over the verifier code, documents and dossier to the platform team. He runs two sessions so they can operate and change it, and he remains available for questions for a month. A smooth handover ensures the work keeps protecting riders after the student project ends.
Worked example
The panel passes Kwame with distinction. Coastline offers him a role on the platform team, and the verifier enters production with the platform team as owner.
Synthetic case. The defense is synthetic.
Errors and limits
A successful defense is the start of practice, not the end of learning.
Exercises
- EX148 — CI provider answer. How did Kwame answer the CI-provider question? Rubric: 3 = provenance untrustworthy; reproducible builds/second builder; 2 = partial; 1 = vague; 0 = none.
- EX149 — Rider data. Does the verifier handle rider data? Rubric: 3 = no, only releases; 2 = partial; 1 = vague; 0 = none.
- EX150 — Next steps. Name Kwame's next steps. Rubric: 3 = certification; working group; platform role; 2 = partial; 1 = vague; 0 = none.
Synthesis
The defense shows engineering judgement across technology, evidence and ethics.
Continue studying — chapter 50 of 50
← Chapter 49 (draft) · Course chapter index · Worked results ↓ · Next course via chapter index →