OpenCyber AcademyLesson map
Lesson 49 published. Map, example, EX145.
flowchart TD
N0["Learning outcomes"]
N1["49.1 Structure"]
N2["49.2 Literature connections"]
N3["49.3 Discussion"]
N4["49.4 Limitations"]
N5["49.5 Future work"]
N6["49.6 Academic standards"]
N7["Writing process"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX145"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["49.1 Structure"]
N2["49.2 Literature connections"]
N3["49.3 Discussion"]
N4["49.4 Limitations"]
N5["49.5 Future work"]
N6["49.6 Academic standards"]
N7["Writing process"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX145"]
[Learning outcomes]
|
v
[49.1 Structure]
|
v
[49.2 Literature connections]
|
v
[49.3 Discussion]
|
v
[49.4 Limitations]
|
v
[49.5 Future work]
|
v
[49.6 Academic standards]
|
v
[Writing process]
|
v
[Worked example] --> [Exercise EX145]
Learning outcomes
You will (1) write an engineering thesis on the capstone; (2) connect design, implementation and evidence to the literature; (3) discuss limitations and future work; (4) meet academic standards.
49.1 Structure
Introduction (problem and need), background (supply chain, SLSA, SSDF, Sigstore, in-toto, reproducible builds), requirements, design, implementation, verification, trial, discussion, conclusion.
The structure follows the engineering work in the order it happened, which helps readers see how each choice led to the next. The background gives readers who do not know supply-chain security enough context to follow the design. Verification and trial chapters present evidence, and the discussion interprets it. Each chapter ends with a link to the next, so the argument reads as one piece. Kwame writes the conclusion last, after the discussion is settled, so it states only what the evidence supports.
49.2 Literature connections
The thesis positions the verifier as a consumer-side check complementary to producer-side controls described in SLSA v1.0 and the SSDF, and relates its use of signing and transparency logs to Newman et al. (2022). It cites Ladisa et al. (2023) to show which attack classes the verifier addresses (distribution-stage tampering) and which it does not (malicious source commits by authorised maintainers).
Naming what the verifier does not address is as important as naming what it does. A reader who assumed the verifier covered malicious commits would trust it for the wrong job. Mapping it onto a published taxonomy lets others compare it with their own controls.
49.3 Discussion
The verifier detects mismatches between built and published apps quickly, but relies on trustworthy build records; reproducible builds would add an independent check.
This dependency on build records is the verifier's main weakness. If the CI provider or build step were compromised, the records would describe the compromised build as legitimate, and the verifier would confirm a match. Reproducible builds would allow a second builder to produce the same output independently, so a mismatch between builders would reveal tampering in one of them. The discussion explains this honestly instead of presenting the verifier as a complete answer.
49.4 Limitations
One organisation, synthetic mismatches, short operating period.
Each limit restricts how far the results can be generalised. One organisation means other transit agencies or app stores might behave differently. Synthetic mismatches test the known types well but may not represent real attacks, which are designed to be hard to detect. A short operating period does not show how the verifier behaves over months of store changes and updates. Kwame explains how each limit affects his conclusions, and which future work would address it.
49.5 Future work
Reproducible mobile builds; sharing verification results among transit agencies.
Each item follows from a limitation. Reproducible mobile builds would address the dependence on trustworthy build records. Sharing results among agencies that use the same app vendor would test the approach in other organisations and could detect a problem affecting many of them at once, building on the external reviewer's suggestion. Kwame describes what each would need, so others can pick them up, including the data each would need and who might provide it.
49.6 Academic standards
Citations are checked against sources; all case data are synthetic or approved.
Checking citations means reading the source to confirm it says what the thesis claims, not copying references from other papers. Kwame finds one case where he had cited a paper for a broader claim than it makes, and he narrows his sentence. Case data are synthetic or approved by Coastline, and the thesis states this clearly, so readers know no confidential details are disclosed. The tutor checks the reference list and the data statement before submission, and any figures from Coastline are confirmed by Ingrid.
Writing process
Kwame writes the thesis in drafts over eight weeks, sharing each chapter with his tutor. He keeps a list of claims and the evidence for each, checking it before submission so every statement is supported. He also asks Ingrid to check the description of Coastline's systems for accuracy and confidentiality before the thesis is submitted.
Abstract and summary
The abstract states the problem, approach, main results and limits in under 300 words, and a plain-language summary is written for Coastline staff.
Submission
The thesis is submitted with the dossier and code archive.
Worked example
Kwame's tutor asks him to cut the background chapter by a third and expand the discussion of limitations; the revised thesis is clearer about what the verifier does not protect against.
Synthetic case. The thesis is synthetic.
Errors and limits
Engineering theses must avoid overclaiming security from a single deployment.
Exercises
- EX145 — Positioning. How is the verifier positioned?
Show marking criteria
Rubric: 3 = consumer-side check complementing producer controls; 2 = partial; 1 = vague; 0 = none. - EX146 — Not covered. Which attack class does the verifier not address?
Show marking criteria
Rubric: 3 = malicious commits by authorised maintainers; 2 = partial; 1 = vague; 0 = none. - EX147 — Tutor change. What did the tutor ask Kwame to change?
Show marking criteria
Rubric: 3 = cut background; expand limitations; 2 = partial; 1 = vague; 0 = none.
Synthesis
An engineering thesis ties built systems to literature and states their limits.
Continue studying — chapter 49 of 50
← Chapter 48 (draft) · Course chapter index · Chapter 50 (draft) →