Chapter 8 — Defense and publication plan | Doctoral research Cloud and container security

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 8 — Defense and publication plan

Lesson map

Lesson 08 published. Map, example, EX045.

flowchart TD
  N0["Learning outcomes"]
  N1["8.1 Preparing"]
  N2["8.2 Expected questions"]
  N3["8.3 Publications"]
  N4["8.4 Data release"]
  N5["8.5 Communicating with practitioners"]
  N6["8.6 Future work"]
  N7["After the defence"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX045"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["8.1 Preparing"]
  N2["8.2 Expected questions"]
  N3["8.3 Publications"]
  N4["8.4 Data release"]
  N5["8.5 Communicating with practitioners"]
  N6["8.6 Future work"]
  N7["After the defence"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX045"]

[Learning outcomes]
    |
    v
[8.1 Preparing]
    |
    v
[8.2 Expected questions]
    |
    v
[8.3 Publications]
    |
    v
[8.4 Data release]
    |
    v
[8.5 Communicating with practitioners]
    |
    v
[8.6 Future work]
    |
    v
[After the defence]
    |
    v
[Worked example] --> [Exercise EX045]

Learning outcomes

You will (1) prepare for the defence; (2) anticipate examiner questions; (3) plan publications and data release; (4) plan responsible communication to practitioners.

8.1 Preparing

Amara rehearses a 30-minute talk: problem, gap, method, result, limits and contribution. Mock examiners ask about generalisation, measurement validity and ethics.

The talk keeps the result in proportion: one slide gives the 14.5-hour median difference with its interval, and the next gives the exceptions, workarounds and rejection rates. Mock examiners' questions on generalisation, measurement validity and ethics map onto the limits already stated in each chapter, so rehearsal tests whether Amara can find them quickly. The rehearsal also tests the answer to the calendar-time question that the real examiners later asked, using the stepped design.

8.2 Expected questions

Would results hold in unmanaged clusters? Possibly not; managed clusters standardise many settings. Is exposure the right outcome? It is a proxy for risk; the thesis argues it is the variable a control can change. Were staff harmed by blocked deployments? Rejection rates and exception handling are reported, and no individual performance data were used.

The real examiners also asked whether teams were simply improving over time. Amara answered with the stepped design: in each calendar month, switched and unswitched clusters were compared, so a general trend would affect both. The thesis passed with minor corrections.

8.3 Publications

Paper 1: the measurement method and archive, at a software engineering venue. Paper 2: the comparison results, at a security venue. A practitioner article explains the findings without partner details.

Splitting the work this way matches the two contributions: the method paper can be evaluated on reproducibility, and the results paper on the comparison. The practitioner article reports the exposure reduction, exception expiry and rejection rates without naming Meridian, its clusters or its teams. Both papers cite the archive's permanent identifier, so readers of either can reach the same scripts and synthetic data.

8.4 Data release

Synthetic data, scripts and policies are released under open licences; partner data are not released, as agreed.

The release includes the synthetic generator, so the method can be reused without Meridian's data, and the manifest, so released files can be checked against what the thesis used. Partner data stay with Meridian under the original agreement. The licences are chosen so that other researchers can modify the generator for their own clusters and publish their changes. The released policy configurations show exactly which Pod Security Standards checks were enforced, so a replication can use the same rules or state how its rules differ.

8.5 Communicating with practitioners

The guidance stresses gradual rollout, exception expiry and measurement, not blanket blocking. It links to the Kubernetes Pod Security Standards and NIST SP 800-190 rather than prescribing a product.

Meridian's own experience gives the guidance its examples: exceptions approved without end dates raised exposure in the step-two clusters, and adding 30-day expiry fixed it. Gradual rollout matters because rejection rates fell from 7% to 3% only after teams had time to adjust. The article also gives the rejection ceiling Amara used, 5% after the first fortnight, as a starting point that teams can adjust.

8.6 Future work

Extending the method to infrastructure-as-code checks before deployment and to multiple organisations.

Checking infrastructure-as-code before deployment would move detection even earlier than admission, into pull requests, and the same exposure measure could compare it with admission enforcement. Extending to several organisations would address the main limit on generalisation: whether a reduction measured at Meridian holds in clusters run by teams with different practices. The archived generator and scripts are designed to make both extensions possible. Meridian's adoption of exception expiry across all clusters gives a natural first follow-up: whether exposure from exceptions falls when every exception has a 30-day end date.

After the defence

Amara makes the corrections within a month, updates the archive with a new manifest and version number, and records the change in the revision log. She presents the practitioner article at an internal Meridian session, where platform engineers ask for the measurement scripts so they can track exposure themselves. Sharing the scripts turns the thesis method into ongoing practice, which she counts as the clearest sign that the contribution was useful.

Worked example

At the defence, the examiners ask whether the effect could be due to teams improving over time. Amara shows the calendar-time check and the stepped design. The thesis passes with minor corrections, and Meridian adopts exception expiry across all clusters.

Synthetic case. Defence and outcomes are synthetic.

Errors and limits

Practitioner summaries tend to drop caveats; keep the key limit in the first paragraph.

Exercises

EX045 — Talk structure. What is the talk structure? Rubric: 3 = problem, gap, method, result, limits, contribution; 2 = four; 1 = two; 0 = none.
EX046 — Exposure proxy. Why use exposure as the outcome? Rubric: 3 = variable the control changes; 2 = partial; 1 = vague; 0 = none.
EX047 — Two papers. What are the two papers? Rubric: 3 = method and archive; comparison results; 2 = partial; 1 = vague; 0 = none.
EX048 — Data release. What is released? Rubric: 3 = synthetic data, scripts, policies; 2 = partial; 1 = vague; 0 = none.
EX049 — Practitioner guidance. What does the guidance stress? Rubric: 3 = gradual rollout, exception expiry, measurement; 2 = two; 1 = one; 0 = none.
EX050 — Time question. How did Amara answer the time-effect question? Rubric: 3 = calendar-time check and stepped design; 2 = partial; 1 = vague; 0 = none.

Synthesis

Defend with evidence, publish openly and communicate carefully.

Continue studying — chapter 08 of 08

← Chapter 07 (draft) · Course chapter index · Worked results ↓ · Next course via chapter index →