Chapter 8 — Application and software supply chain security: failure modes
Lesson map
Lesson 08 published. Map, example, EX029.
flowchart TD
N0["Learning outcomes"]
N1["8.1 Changed downloads"]
N2["8.2 Outdated components"]
N3["8.3 Abandoned components"]
N4["8.4 Compromised publishers"]
N5["8.5 Misconfiguration"]
N6["8.6 Blame-free review"]
N7["Using the list in tickets"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX029"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["8.1 Changed downloads"]
N2["8.2 Outdated components"]
N3["8.3 Abandoned components"]
N4["8.4 Compromised publishers"]
N5["8.5 Misconfiguration"]
N6["8.6 Blame-free review"]
N7["Using the list in tickets"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX029"]
[Learning outcomes]
|
v
[8.1 Changed downloads]
|
v
[8.2 Outdated components]
|
v
[8.3 Abandoned components]
|
v
[8.4 Compromised publishers]
|
v
[8.5 Misconfiguration]
|
v
[8.6 Blame-free review]
|
v
[Using the list in tickets]
|
v
[Worked example] --> [Exercise EX029]
Learning outcomes
You will (1) list the ways the supply chain to a customer site can fail; (2) link each to a check; (3) recognise them in support tickets; (4) avoid blaming individuals.
8.1 Changed downloads
A file from an unofficial source differs from the release, as in the Ferncroft case. Check: official sources and hash verification. The Ferncroft mirror copy is this failure exactly: the file looked like resize-plugin 2.4.1 but its hash began 5af89d46d94f instead of matching the vendor's. The two checks address different moments, since an official source reduces the chance of a bad file and the hash proves the file received is the released one. Both checks now sit in the installation procedure as mandatory steps.
8.2 Outdated components
A plugin version with a published advisory stays installed because nobody tracks versions. Kula et al. (2018) found that developers often leave dependencies outdated. Check: inventory and advisory comparison. Without the inventory, Pinecrest could not compare installed versions with advisories at all. The advisory lab later finds alder-dental and quayside-gym running contact-form versions older than the fixed 5.1.0. Those are the kind of outdated installations that stay unnoticed when nobody tracks versions across sites. The nightly inventory makes this comparison routine instead of a rare manual task.
8.3 Abandoned components
A plugin's author stops maintaining it; future flaws will never be fixed. Check: review maintenance activity yearly and replace abandoned plugins. An abandoned plugin can look fine for years, then a flaw is published and no fix ever arrives. The yearly maintenance review catches this before an advisory forces a rushed replacement. The yearly review looks at recent release dates, open issues and whether security notices are answered, and replacement plugins go through the normal installation procedure with hash checks.
8.4 Compromised publishers
A legitimate vendor's account or build is misused to publish a harmful update. Ladisa et al. (2023) catalogue such attacks on open-source supply chains, and Ohm et al. (2020) describe harmful packages. Check: watch for unexpected changes after updates and follow vendor security notices. This failure mode differs from Ferncroft's because the harmful file would come from the vendor itself, with a matching hash. File-change monitoring and error rates after updates are the main signals support has. Following vendor security notices also tells support when a release has been withdrawn.
8.5 Misconfiguration
Correct software configured badly, such as writable code folders or missing security headers. Check: baseline checks. At Ferncroft the writable plugin folder was this kind of failure, and in the header lab alder-dental and quayside-gym miss baseline headers. The software itself may be correct while its settings leave it exposed. Baseline checks compare every site against the same written standard, so drift shows up as a named finding rather than a vague doubt. Fixes go through the server template where possible, so all sites benefit at once.
8.6 Blame-free review
Failures are treated as process problems; the technician who used the mirror followed no rule because none existed. The previous technician used the mirror because the vendor's page was slow and no rule required an official source or a hash check. Blaming that person would teach staff to hide shortcuts rather than report them. In Grace's review, the technician helps write the new rules, which also makes them more practical. The review notes also record the rules that were missing, not the person involved.
Using the list in tickets
Tomás keeps the failure-mode list beside the ticket queue. When a ticket mentions strange redirects, new admin users or pages changing on their own, he checks for changed files and recent plugin updates first. When a ticket asks for a plugin installation, he checks source, hash and maintenance before agreeing. The list turns vague worries into specific questions with specific checks.
Worked example
Grace runs a short review of the Ferncroft case using these failure modes. Three applied: changed download, misconfiguration and, initially, no inventory to detect outdated components. The review results in new rules, not blame, and the technician involved helps write them.
Synthetic case. Cases are synthetic.
Errors and limits
Some failures cannot be prevented by a consumer, only detected quickly.
Exercises
- EX029 — Changed download check. What checks prevent changed downloads? Rubric: 3 = official sources, hash verification; 2 = partial; 1 = vague; 0 = none.
- EX030 — Abandoned plugins. How are abandoned plugins handled? Rubric: 3 = review yearly; replace; 2 = partial; 1 = vague; 0 = none.
- EX031 — Compromised publisher. Why can't consumers fully prevent publisher compromise? Rubric: 3 = legitimate channel; detect quickly; 2 = partial; 1 = vague; 0 = none.
- EX032 — Blame-free. Why was the review blame-free? Rubric: 3 = no rule existed; process problem; 2 = partial; 1 = vague; 0 = none.
Synthesis
Know the failure modes and link each to a check.
Continue studying — chapter 08 of 18
← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →