Chapter 26 — Application and software supply chain security: operational handoff
Lesson map
Lesson 26 published. Map, example, EX076.
flowchart TD
N0["Learning outcomes"]
N1["26.1 What is handed over"]
N2["26.2 Runbooks"]
N3["26.3 Responsibilities"]
N4["26.4 Checking the handoff"]
N5["26.5 Client communication"]
N6["26.6 Keeping knowledge"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX076"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["26.1 What is handed over"]
N2["26.2 Runbooks"]
N3["26.3 Responsibilities"]
N4["26.4 Checking the handoff"]
N5["26.5 Client communication"]
N6["26.6 Keeping knowledge"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX076"]
[Learning outcomes]
|
v
[26.1 What is handed over]
|
v
[26.2 Runbooks]
|
v
[26.3 Responsibilities]
|
v
[26.4 Checking the handoff]
|
v
[26.5 Client communication]
|
v
[26.6 Keeping knowledge]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX076]
Learning outcomes
You will (1) hand over security processes to the team that will run them; (2) write runbooks; (3) define responsibilities; (4) check the handoff works.
26.1 What is handed over
As the placement nears its end, Diego hands over the nightly job, the inventory, the upload checks module, the pipeline template and the drift check. Each needs an owner who will keep it running after he leaves; otherwise the controls will slowly decay as libraries and platforms change around them. Each item is something the agency now relies on daily, built during Diego's placement. For each item Diego lists where its code lives, what it depends on and who uses its output.
26.2 Runbooks
Each process gets a runbook: what it does, how to tell it is healthy, what common failures look like and how to fix them, and who to contact. Runbooks are written for a developer who has never seen the process, and tested by having one follow them. A developer who follows a runbook without help shows that the steps are complete. A runbook also states what not to do, such as never disabling a failing check to clear the nightly report. It links to the troubleshooting page entries that concern the process, so a new owner can see which failures have happened before and how they were solved.
26.3 Responsibilities
A simple table names who owns each process, who is the backup, and who approves changes. Advisory response is shared: the nightly job finds matches, project owners fix them, and Aiko watches the due dates each week. Naming a backup matters because a process with one person who understands it stops when that person is away. The table also records who approves changes, so the nightly job's matching logic or the pipeline template cannot be edited without a named reviewer. Weekly checking of due dates by Aiko keeps the 7-day target visible across all owners.
26.4 Checking the handoff
For two weeks the new owners run everything while Diego only watches. Any question they have to ask him becomes a runbook update. The watched fortnight tests the handoff under real conditions rather than in a meeting. Diego answers questions but does not run any step himself, so gaps in the runbooks become visible. Eleven questions came up, and each became a runbook update before he left. The new owners also handle one real advisory match during the fortnight, following the runbook from task to fix.
26.5 Client communication
Clients are told who their security contact is and how advisories affecting them will be reported. Each client's note names the Brightwave contact, explains that advisories affecting their site will be reported with what was done, and states the agreed response times from their contract. Greenleaf's clinic manager, the incident contact in the inventory's context note, receives the first of these. Clients who never had an affected library still learn how they would be told. Clients are also told that a quiet month means no affected advisories, not a missed report.
26.6 Keeping knowledge
Decisions and reasons are kept in the repositories next to the code, not in personal notes. Diego's reasons for decisions, such as the 180-day threshold for upload, authentication and payment libraries or the hold list in the drift check, are written into the repositories that use them. A new owner reading the code finds the explanation next to it. Personal notes would leave with Diego at the end of the placement, along with the reasons behind the controls. Repositories keep this knowledge reviewed alongside the code it explains, in the same pull requests.
Worked example
During the watched fortnight, the new owner of the nightly job cannot find how to add a new client project to the inventory. Diego adds a step to the runbook; the next new project is added without help. By the end, the owners have asked eleven questions, all now answered in the runbooks.
Synthetic case. Processes and events are synthetic.
Errors and limits
A handoff is finished when others can run the process without you, not when the documents exist.
Exercises
- EX076 — Runbook contents. What does a runbook include? Rubric: 3 = purpose, health, failures, fixes, contacts; 2 = three; 1 = one; 0 = none.
- EX077 — Advisory roles. Who does what in advisory response? Rubric: 3 = job finds; owners fix; Aiko watches dates; 2 = two; 1 = one; 0 = none.
- EX078 — Handoff check. How was the handoff checked? Rubric: 3 = two weeks owners run, Diego watches; 2 = partial; 1 = vague; 0 = none.
Synthesis
Hand over with runbooks, owners and a watched trial.
Continue studying — chapter 26 of 30
← Chapter 25 (draft) · Course chapter index · Chapter 27 (draft) →