Chapter 13 — Application and software supply chain security: risk scenarios
Lesson map
Lesson 13 published. Map, example, EX037.
flowchart TD
N0["Learning outcomes"]
N1["13.1 Writing scenarios"]
N2["13.2 Supply chain scenarios"]
N3["13.3 Likelihood and impact"]
N4["13.4 Linking controls"]
N5["13.5 Review"]
N6["13.6 Ranking"]
N7["Scenario register"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX037"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["13.1 Writing scenarios"]
N2["13.2 Supply chain scenarios"]
N3["13.3 Likelihood and impact"]
N4["13.4 Linking controls"]
N5["13.5 Review"]
N6["13.6 Ranking"]
N7["Scenario register"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX037"]
[Learning outcomes]
|
v
[13.1 Writing scenarios]
|
v
[13.2 Supply chain scenarios]
|
v
[13.3 Likelihood and impact]
|
v
[13.4 Linking controls]
|
v
[13.5 Review]
|
v
[13.6 Ranking]
|
v
[Scenario register]
|
v
[Worked example] --> [Exercise EX037]
Learning outcomes
You will (1) write risk scenarios for client apps and the supply chain; (2) estimate likelihood and impact; (3) link scenarios to controls; (4) review them.
13.1 Writing scenarios
A scenario says what could happen, through which weakness, and what harm follows: "An outdated upload library with a known flaw lets a visitor's upload affect the server, exposing medical records." Scenarios describe outcomes, not procedures. Diego keeps each scenario to one or two sentences and names Greenleaf's data where relevant, so readers can picture the harm without needing technical detail. Describing outcomes keeps the register safe to share with clients and students, because it records harm and weakness rather than any method of causing it. The January scenario names the outdated library, the public upload form and the medical records together, which is enough to decide which controls matter. A scenario that cannot name its harm is rewritten before it is rated.
13.2 Supply chain scenarios
Ladisa et al. (2023) catalogue attacks on open-source supply chains, such as a library maintainer's account being taken over and a harmful version published. Ohm et al. (2020) studied real malicious packages. Brightwave writes scenarios for these kinds of events at the level of "a harmful library version enters a build". These scenarios differ from the January case because the harmful version may have no advisory yet. An inventory alone would show which clients installed it, but only pinning, review and an adoption delay could stop it entering a build in the first place. Brightwave does not try to model the attacker's method; it records which of its own controls would apply.
13.3 Likelihood and impact
Each scenario gets low, medium or high for likelihood and impact, using evidence: advisories seen, exposure, data held, number of clients. For the outdated-library scenario, the January advisory, Greenleaf's public upload form, medical notes and 23 projects sharing libraries all point to high likelihood and high impact. A scenario about the internal status page scores lower on exposure, because only staff and client contacts can reach it. Each rating cites its evidence so the next review can test whether it still holds.
13.4 Linking controls
Each scenario lists its controls: for a harmful library version, pinned versions with hashes, a short delay before adopting brand-new versions, and review of dependency changes. Writing the controls beside each scenario shows quickly which ones are missing. Before this course, the harmful-version scenario had review of code changes but no review of lockfile changes and no adoption delay, so two of its three controls were gaps. Each control is also linked to the chapter of the course where it is built, so progress can be checked against the plan.
13.5 Review
Scenarios are reviewed every six months and after any incident. The six-month review asks whether each rating still matches the evidence, whether any control has been added or lost, and whether any new advisory or incident fits no existing scenario. After an incident the review happens within weeks rather than waiting, so lessons reach the register while the details are fresh. The review compares each rating with the evidence gathered since the last one. After the form-library advisory, for example, the scenario about shared libraries keeps its high rating because eight clients were affected at once. A control that has stopped working, such as a pipeline check someone disabled, moves its scenario back up the list.
13.6 Ranking
The top five scenarios get named owners and target dates for missing controls. Ranking keeps the register from becoming a list nobody acts on. With about fifteen rows, the top five are a manageable set for a small agency. Each owner reports progress at the monthly meeting, and a missed target date is discussed there rather than quietly moved. The top-ranked scenario, an outdated library with a known flaw in a public client app, is owned by Aiko, with Diego building its first controls. Ranking is revisited at each review, so a scenario whose controls are all in place can drop out of the top five and free attention for the next one.
Scenario register
Scenarios are kept in a shared register with columns for the scenario, likelihood, impact, evidence, controls in place, missing controls, owner and review date. The register is short, about fifteen rows, so it is actually read. When a new advisory or incident does not fit any existing scenario, a new row is added, which shows where earlier thinking missed something.
Worked example
The top-ranked scenario is "an outdated library with a known flaw in a public client app", rated high likelihood and high impact because of the January case. Its controls (inventory, audits, weekly updates) are the first built in this course.
Synthetic case. Scenarios and ratings are synthetic.
Errors and limits
Ratings are estimates; record the evidence behind each.
Exercises
- EX037 — Scenario parts. What does a scenario state? Rubric: 3 = what, weakness, harm; 2 = two; 1 = one; 0 = none.
- EX038 — Harmful version controls. Name controls for a harmful library version. Rubric: 3 = pinning with hashes; adoption delay; review; 2 = two; 1 = one; 0 = none.
- EX039 — Top scenario. What was the top-ranked scenario? Rubric: 3 = outdated library with known flaw in public app; 2 = partial; 1 = vague; 0 = none.
Synthesis
Scenarios link evidence to controls and priorities.
Continue studying — chapter 13 of 30
← Chapter 12 (draft) · Course chapter index · Chapter 14 (draft) →