Chapter 7 — Dissertation writing and limitations
Lesson map
Lesson 07 published. Map, example, EX039.
flowchart TD
N0["Learning outcomes"]
N1["7.1 Structure"]
N2["7.2 Limitations"]
N3["7.3 Confidentiality"]
N4["7.4 Linking to standards"]
N5["7.5 Plain summary"]
N6["7.6 Writing style"]
N7["Figures"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX039"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["7.1 Structure"]
N2["7.2 Limitations"]
N3["7.3 Confidentiality"]
N4["7.4 Linking to standards"]
N5["7.5 Plain summary"]
N6["7.6 Writing style"]
N7["Figures"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX039"]
[Learning outcomes]
|
v
[7.1 Structure]
|
v
[7.2 Limitations]
|
v
[7.3 Confidentiality]
|
v
[7.4 Linking to standards]
|
v
[7.5 Plain summary]
|
v
[7.6 Writing style]
|
v
[Figures]
|
v
[Worked example] --> [Exercise EX039]
Learning outcomes
You will (1) structure a dissertation for a security audience; (2) write limitations that inform rather than apologise; (3) present findings without exposing a company; (4) connect results to practice standards.
7.1 Structure
Introduction, literature, method, results, competing explanations, discussion, limitations, conclusion. Each chapter answers one question.
Giving competing explanations their own chapter, before the discussion, makes the reader meet the framework change, the senior developer and pentest effort before any interpretation of the 0.14 ratio. Each chapter answers one question, so the examiners can find, for example, how tester focus was checked without reading the whole results chapter. The structure also mirrors the proposal Dr Lee approved, so an examiner can compare what was planned with what was done chapter by chapter. Any change between the two is listed in the method chapter with its reason.
7.2 Limitations
One company, one application, twelve releases; a framework change during the study; pentest skill variation; tests in a test environment. Each limitation says what it means for the claim and how future work could address it.
Dr Lee called this the most useful part for practitioners, because it tells them when the approach may not work. Apps with hundreds of dynamic roles, for example, may not be manageable with a hand-written matrix; the dissertation says so, and proposes generating the matrix from the role definitions as future work.
7.3 Confidentiality
Tallyline is named only with permission, figures are rounded, and examples are synthetic versions of real flaws.
Rounding stops a reader from linking a figure to a specific Tallyline release or customer. The synthetic examples keep the shape of the real flaws, such as reading another business's invoice by changing a number, without the real endpoint names or parameters. Tallyline's legal team reviewed the final text against these rules before submission, the same team that approved use of the anonymised finding counts at the start. Their review is recorded with the ethics approval.
7.4 Linking to standards
The discussion recommends role-matrix tests as a way to meet ASVS authorisation requirements continuously and to evidence SSDF PW.8 and SAMM verification.
Continuously means on every build, not once a year: a role-matrix test that fails the build gives Tallyline evidence for PW.8 every time it runs. The discussion also notes the limit: the tests check only what the matrix lists, so ASVS requirements for complete coverage depend on the route completeness check as well. For that reason it recommends running the route check in the same build as the tests, so an unmapped route fails the build just as a wrong decision does.
7.5 Plain summary
A one-page summary for Tallyline's engineering team avoids jargon.
It gives the main result as "access-control findings fell sharply after the tests; part of the fall came from the framework upgrade", states that results were never used to assess individuals, and asks developers to keep the matrix and route check up to date. Each sentence matches a claim in the dissertation. The summary also explains the route completeness check in one sentence, because it is the step most likely to be dropped once the study ends and the person who wrote it moves on. A matrix that stops matching the routes would quietly stop testing new endpoints.
7.6 Writing style
Claims are tied to evidence with hedges where needed: "was followed by", "is consistent with".
When a sentence in the draft said the tests "reduced" findings, Sofia changed it to "was followed by a reduction", because the design shows sequence and association rather than proof of cause. The framework change makes the hedge necessary, not merely cautious. The hedges are not decoration: each one corresponds to a limitation stated in the limitations chapter, such as the framework change or the twelve-release sample, so a reader can see why the claim is worded as it is.
Figures
Each figure has a clear caption stating what it shows and its data source.
Abstract
The abstract states question, method, main result with its uncertainty, the main limitation and the practical implication in under 250 words. Sofia rewrites it five times, each time asking a colleague outside security whether they understand the result. A clear abstract decides whether practitioners read on.
Recommendations
The final chapter lists recommendations by audience. For developers: write an authorisation test for every new endpoint as part of the definition of done. For product managers: decide and record roles before building features. For security teams: use the matrix as the basis for penetration test scoping, so testers focus on gaps rather than re-checking covered cases.
Worked example
Dr Lee reads the limitations section and comments that it is the most useful part for practitioners, because it tells them when the approach may not work, such as apps with hundreds of dynamic roles.
Synthetic case. Text and feedback are synthetic.
Errors and limits
Over-hedging can hide useful findings; balance caution with clarity.
Exercises
- EX039 — Chapter list. List the dissertation chapters. Rubric: 3 = intro, literature, method, results, alternatives, discussion, limitations, conclusion; 2 = six; 1 = three; 0 = none.
- EX040 — Limitation form. What must each limitation state? Rubric: 3 = meaning for claim; future work; 2 = partial; 1 = vague; 0 = none.
- EX041 — Confidentiality. How is Tallyline protected? Rubric: 3 = named with permission; rounded; synthetic examples; 2 = partial; 1 = vague; 0 = none.
- EX042 — Standards link. How do results link to ASVS and SSDF? Rubric: 3 = continuous ASVS authorisation; evidence PW.8; 2 = partial; 1 = vague; 0 = none.
- EX043 — Hedging words. Give a hedged phrasing. Rubric: 3 = "was followed by", "consistent with"; 2 = partial; 1 = vague; 0 = none.
- EX044 — Dynamic roles. When might the approach not work? Rubric: 3 = apps with hundreds of dynamic roles; 2 = partial; 1 = vague; 0 = none.
Synthesis
Write limitations that guide practitioners and claims that match evidence.
Continue studying — chapter 07 of 08
← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →