◇ OpenCyber Academy
Postgraduate · Chapter 12 · English

Chapter 12 — Final review and transfer

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 12 — Final review and transfer

Lesson map

Lesson 12 published. Map, example, EX056.

flowchart TD
  N0["Learning outcomes"]
  N1["12.1 Looking back"]
  N2["12.2 Transfer"]
  N3["12.3 Sustainability"]
  N4["12.4 Sharing"]
  N5["12.5 Personal goals"]
  N6["12.6 Next steps"]
  N7["What changed in practice"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX056"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["12.1 Looking back"]
  N2["12.2 Transfer"]
  N3["12.3 Sustainability"]
  N4["12.4 Sharing"]
  N5["12.5 Personal goals"]
  N6["12.6 Next steps"]
  N7["What changed in practice"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX056"]

[Learning outcomes]
    |
    v
[12.1 Looking back]
    |
    v
[12.2 Transfer]
    |
    v
[12.3 Sustainability]
    |
    v
[12.4 Sharing]
    |
    v
[12.5 Personal goals]
    |
    v
[12.6 Next steps]
    |
    v
[What changed in practice]
    |
    v
[Worked example] --> [Exercise EX056]

Learning outcomes

You will (1) review the course's learning against practice; (2) transfer lessons to other contexts; (3) plan sustainable ownership; (4) set personal development goals.

12.1 Looking back

From an unreviewed SDK update to a governed, measured process, Hannah's course connected decisions, evidence, design, evaluation, integration and assurance.

Each chapter answered a question the previous one raised: what to decide, which practices were missing, which findings mattered, what was fair to customers, how to build the control, whether it worked, how to fit it into daily work, how to handle hard cases, and how to show it to others. Hannah keeps the February incident as the thread linking them, because every later choice can be traced back to it.

12.2 Transfer

The same pattern applies to browser scripts on the web banking site and to internal shared libraries: inventory, behaviour diff, isolation where needed, contracts or ownership, and indicators.

Browser scripts on the web banking site behave much like mobile SDKs: they come from third parties, change without notice and run with the page's access to customer data. Hannah proposes extending the harness to record script destinations on the site, with the same register and review rules. Internal libraries need ownership and signing rather than contracts, which links to the reading group's Sigstore-style pilot.

12.3 Sustainability

The SDK register and harness have named owners; the indicators are part of quarterly reporting; training is in onboarding.

Each owner has a deputy, so the harness and register keep running during leave or staff changes. Indicator definitions are documented, so the quarterly figures do not depend on Hannah producing them herself. The CISO reviews the programme once a year and decides whether its targets need changing. Training material is updated whenever a new case study is written, so onboarding reflects the latest difficult cases.

12.4 Sharing

Hannah presents an anonymised version at an industry forum, with all examples synthetic.

Before presenting, she removes vendor names and replaces the bank's figures with synthetic ones, and the bank's communications team approves the slides. The talk focuses on the method, behaviour diffs plus a register, which other banks can adapt to their own apps. She invites listeners to share their own results, since closed-source SDK verification is still an open problem across the sector. Questions from the forum feed into her list of research gaps.

12.5 Personal goals

Deepen knowledge of build provenance (SLSA levels) and contribute to an open-source verification tool.

Both goals grow from the research gaps in chapter 10: verifying closed-source components and making provenance routine. Hannah plans to start by reading the SLSA specification in full and joining the community discussions of an open-source verification project. She agrees with Dr Menon to review her progress against these goals in six months. Contributing in the open also lets her test whether her ideas hold outside Northbridge.

12.6 Next steps

Further study in the next course of the curriculum.

Hannah will carry her SDK register, diff harness design and evaluation method into the next course as worked material. Dr Menon advises her to choose a topic linked to the open questions from chapter 10, such as verifying closed-source SDKs that offer no provenance. Before starting, she writes a short handover for the register's owner at Northbridge, listing open actions, the legacy app's exception date and the indicators to report each quarter. The handover is stored with the project report, and she agrees to answer questions from the team during the first months.

What changed in practice

Before the course, SDK updates arrived unseen; after it, every update is diffed, reviewed when behaviour changes, and recorded in a register linked to contracts. Detection fell from 19 days to about two. The number of SDKs fell by a third. The board receives evidence each quarter, and the regulator has seen the follow-up. Hannah notes that most of the gains came from making things visible and assigning owners, not from expensive tools.

Advice to others

Hannah's advice to peers in other banks: start with an inventory of third-party code and what data it touches; make behaviour changes visible automatically; agree owners across engineering, privacy and procurement; and measure a few indicators that link to real incidents. Avoid starting with large tool purchases before the process and owners exist.

Worked example

Dr Menon asks which single change mattered most. Hannah answers: making SDK behaviour changes visible automatically; everything else depended on seeing them.

Synthetic case. The review is synthetic.

Errors and limits

Lessons from one bank may not suit organisations without similar resources; adapt.

Exercises

Synthesis

Transfer the pattern, sustain ownership and keep learning.

Continue studying — chapter 12 of 12

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