Chapter 31 — Application and software supply chain security: advanced cases
Lesson map
Lesson 31 published. Map, example, EX091.
flowchart TD
N0["Learning outcomes"]
N1["31.1 Abandoned dependency"]
N2["31.2 Maintainer change"]
N3["31.3 Uncertainty"]
N4["31.4 Upstream communication"]
N5["31.5 Combined issues"]
N6["31.6 Balance"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX091"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["31.1 Abandoned dependency"]
N2["31.2 Maintainer change"]
N3["31.3 Uncertainty"]
N4["31.4 Upstream communication"]
N5["31.5 Combined issues"]
N6["31.6 Balance"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX091"]
[Learning outcomes]
|
v
[31.1 Abandoned dependency]
|
v
[31.2 Maintainer change]
|
v
[31.3 Uncertainty]
|
v
[31.4 Upstream communication]
|
v
[31.5 Combined issues]
|
v
[31.6 Balance]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX091]
Learning outcomes
You will (1) analyse complex situations combining application and supply-chain issues; (2) reason about maintainer compromise and abandoned packages; (3) plan responses under uncertainty; (4) communicate with upstream projects.
31.1 Abandoned dependency
A small image-resizing package CampusEats uses has had no release for three years; an advisory reports a flaw with no fix. Options: replace it, maintain a fixed copy internally, or remove the feature (dish photos). The society replaces it with a maintained library, after checking its maintenance activity and number of maintainers.
Maintaining a fixed copy would have made the society responsible for a library none of its members understood well, and removing dish photos would have upset the cafés. Lena records the choice in a decision record with the evidence about the new library, and the owner list is updated so the replacement has a named owner from the start.
31.2 Maintainer change
A package's maintainer hands it to a new, unknown account, and a new version adds an install script. Ohm et al. (2020) noted takeovers of existing packages as a pattern in malicious package cases. The society holds the update, checks the change notes and the script's purpose, and asks in the project's issue tracker. The script turns out to be a legitimate build step, but the society keeps the update on hold until other users confirm.
Lena notes in the dependency's record what was checked and who decided, so the hold is not forgotten.
31.3 Uncertainty
Often you cannot know quickly whether a change is malicious. Holding updates is safe if the current version has no known issues; pin and wait.
Lena writes the rule down for the society: if a change cannot be explained and the current version is safe, the update waits. Each hold has an owner and a date to look again, so a precaution does not become a permanent freeze that leaves CampusEats behind on later fixes. If an advisory later affects the pinned version, the hold must be resolved immediately rather than at its planned date.
31.4 Upstream communication
Polite, specific questions in public trackers help everyone; private reports go through security contacts.
Lena's question about the install script was short, named the version and the file, and asked only what it did, without accusing anyone. The new maintainer answered within a day, and other users found the answer useful. Anything that might be a vulnerability goes instead to the project's security contact, as described in the ethics chapter, so it is not made public before a fix exists.
31.5 Combined issues
A flaw in a template library could allow cross-site scripting only if the app uses a rare feature. Checking reachability prevents panic: CampusEats does not use it, but updates anyway.
Lena checks reachability by searching the CampusEats templates for the affected feature and confirming that the template engine is configured without it. She records the evidence, so the decision does not depend on memory. Updating anyway costs little through the weekly process and removes the need to recheck if a future feature starts using the affected code.
31.6 Balance
Each response balances risk, effort and the volunteers' time.
The society cannot investigate every update in depth, so it puts most effort where the risk is highest: packages that run at install time, handle payments or run in students' browsers. Routine updates to small, well-maintained development tools get less attention. Lena writes these tiers into the handbook, so members know which changes need a careful look and which can follow the normal weekly process. Grace reviews the tiers each year.
Worked example
Three weeks after the maintainer change, the society checks the package again: the new maintainer is now listed on the project's website, other projects report no problems, and a security reviewer from a larger project has looked at the install script. The hold is lifted.
Synthetic case. Packages and events are synthetic.
Errors and limits
Waiting for others to confirm safety relies on someone else checking; for critical packages, review it yourself.
Exercises
- EX091 — Abandoned options. List the options for the abandoned package. Rubric: 3 = replace, maintain copy, remove feature; 2 = two; 1 = one; 0 = none.
- EX092 — Maintainer response. How did the society respond to the maintainer change? Rubric: 3 = hold update; check notes/script; ask; wait for confirmation; 2 = partial; 1 = vague; 0 = none.
- EX093 — Reachability. Why did reachability matter for the template flaw? Rubric: 3 = rare feature not used; no panic; 2 = partial; 1 = vague; 0 = none.
Synthesis
In complex cases, hold safely, gather evidence and communicate with upstream.
Continue studying — chapter 31 of 40
← Chapter 30 (draft) · Course chapter index · Chapter 32 (draft) →