Chapter 3 — Application and software supply chain security: systems, data and dependencies
Lesson map
Lesson 03 published. Map, example, EX027.
flowchart TD
N0["Learning outcomes"]
N1["3.1 Listing components"]
N2["Lab — component review"]
N3["3.2 Lab result"]
N4["3.3 Why maintenance matters"]
N5["3.4 Data flows"]
N6["3.5 Deciding"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX027"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["3.1 Listing components"]
N2["Lab — component review"]
N3["3.2 Lab result"]
N4["3.3 Why maintenance matters"]
N5["3.4 Data flows"]
N6["3.5 Deciding"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX027"]
[Learning outcomes]
|
v
[3.1 Listing components]
|
v
[Lab — component review]
|
v
[3.2 Lab result]
|
v
[3.3 Why maintenance matters]
|
v
[3.4 Data flows]
|
v
[3.5 Deciding]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX027]
Learning outcomes
You will (1) list the website's components and versions; (2) check advisories, maintenance and use; (3) map where donor data flows; (4) decide to update, replace or remove each component.
3.1 Listing components
Owen exports the plugin list from the site's administration page: name, version and whether each is active. He adds the theme, the platform version and the outside services the site calls: the payment provider and the newsletter service. This list is the charity's inventory, the base for every other check.
Writing down which plugins are active matters: photo-gallery appears in the list but is not in use, and an unused plugin still has code on the server that an attacker could reach. Adding the payment provider and the newsletter service shows where donor data leaves the site, which is needed for the data-flow check later in the week.
Lab — component review
"""Review a synthetic list of website components: advisories, maintenance and use (stdlib only)."""
from datetime import date
today = date(2026, 10, 1)
components = [ # name, version, fixed_version_or_None, last_release, in_use
("donate-form", "3.2.0", "3.2.4", date(2026, 8, 2), True),
("event-calendar", "1.4.1", None, date(2022, 5, 9), True),
("photo-gallery", "2.0.0", None, date(2026, 6, 20), False),
("newsletter", "5.1.3", None, date(2026, 9, 1), True),
]
def v(s): return tuple(map(int, s.split(".")))
for name, ver, fixed, last, used in components:
notes = []
if fixed and v(ver) < v(fixed):
notes.append(f"UPDATE to {fixed}")
if (today - last).days > 730:
notes.append(f"UNMAINTAINED ({(today - last).days} days since release)")
if not used:
notes.append("REMOVE (not in use)")
print(f"{name:15} {ver:6} {'; '.join(notes) or 'ok'}")
Run with python3 lab_deps.py. Verified output:
donate-form 3.2.0 UPDATE to 3.2.4
event-calendar 1.4.1 UNMAINTAINED (1606 days since release)
photo-gallery 2.0.0 REMOVE (not in use)
newsletter 5.1.3 ok
3.2 Lab result
donate-form 3.2.0 must be updated to 3.2.4, the version that fixes a published advisory. event-calendar 1.4.1 is flagged UNMAINTAINED: its last release was 1,606 days ago. photo-gallery 2.0.0 is flagged REMOVE because it is not in use. newsletter 5.1.3 is ok. Each flag leads to a different action: update, replace or remove.
The lab's rules are simple enough to check by hand. A component is UNMAINTAINED if its last release is more than 730 days, about two years, before the review date of 1 October 2026; event-calendar's last release was 9 May 2022. The script compares versions as numbers, so it would correctly flag a version like 3.10 as newer than 3.9.
3.3 Why maintenance matters
A component with no releases for years will not receive fixes for future flaws. Kula et al. (2018) found that outdated dependencies are common because updating takes effort; Zimmermann et al. (2019) showed that a few maintainers can affect very many users. Small sites benefit from choosing popular, actively maintained components.
Owen's event-calendar shows the risk: 1,606 days without a release means that any flaw found in it now will probably never be fixed. When he chooses a replacement, he checks the release history and how many sites use it, so that the new calendar is less likely to be abandoned too.
3.4 Data flows
Donor details move from the donation form to the site's database, the card details go directly to the payment provider's page, and email addresses go to the newsletter service if the donor opts in. Each flow is a place to check: the form component, database access, the payment hand-off and the newsletter connection.
The newsletter flow depends on the donor's choice: only donors who tick the box are sent to the newsletter service, so Owen checks that the box is unticked by default. The payment hand-off is the most sensitive point: if the form were changed to collect card numbers itself, they would pass through the charity's site, which is exactly what the current design avoids.
3.5 Deciding
Update donate-form now (it handles donor data and has an advisory). Replace event-calendar with a maintained alternative within the month. Remove photo-gallery after confirming nobody needs it. Keep newsletter and turn on automatic security updates where the host supports them.
Owen's later discovery changed one priority: event-calendar also stored volunteers' phone numbers for shift sign-ups, which nobody remembered. That moved its replacement up to week 3, with the phone numbers moved to the charity's existing volunteer system and deleted from the website. A decision list is a plan, not a promise; it changes when new facts appear.
Worked example
Owen reruns the three priority questions for event-calendar after the discovery. Likelihood is unchanged: with no release for 1,606 days, any future flaw stays unfixed. Harm is higher, because the plugin also holds volunteers' phone numbers. The fix cost is unchanged: a maintained alternative. Higher harm alone is enough to move the replacement up to week 3.
Synthetic case. Components, dates and data are synthetic.
Errors and limits
A component list from the admin page may miss files added by hand; ask the host if unsure.
Exercises
- EX027 — Inventory fields. What does Owen's inventory record? Rubric: 3 = name, version, active, plus theme, platform, services; 2 = three; 1 = one; 0 = none.
- EX028 — donate-form action. What does the lab say about donate-form? Rubric: 3 = update 3.2.0 to 3.2.4; 2 = partial; 1 = vague; 0 = none.
- EX029 — event-calendar flag. Why is event-calendar flagged? Rubric: 3 = 1,606 days without a release; 2 = partial; 1 = vague; 0 = none.
- EX030 — photo-gallery flag. What should happen to photo-gallery? Rubric: 3 = remove; not in use; 2 = partial; 1 = vague; 0 = none.
- EX031 — Card flow. Where do card details go? Rubric: 3 = directly to payment provider; 2 = partial; 1 = vague; 0 = none.
- EX032 — Newsletter flow. When does an email reach the newsletter service? Rubric: 3 = if donor opts in; 2 = partial; 1 = vague; 0 = none.
- EX033 — Maintenance research. What did Kula et al. find? Rubric: 3 = outdated dependencies common; 2 = partial; 1 = vague; 0 = none.
- EX034 — Choosing components. What kind of components suit small sites? Rubric: 3 = popular, actively maintained; 2 = partial; 1 = vague; 0 = none.
- EX035 — Hidden data. What did Owen discover about event-calendar? Rubric: 3 = stored volunteers' phone numbers; 2 = partial; 1 = vague; 0 = none.
- EX036 — Phone numbers. What happened to the phone numbers? Rubric: 3 = moved to volunteer system; deleted; 2 = partial; 1 = vague; 0 = none.
- EX037 — Three actions. Name the three possible actions. Rubric: 3 = update, replace, remove; 2 = two; 1 = one; 0 = none.
- EX038 — Admin page gap. What might the admin page list miss? Rubric: 3 = files added by hand; 2 = partial; 1 = vague; 0 = none.
Synthesis
Inventory, check and decide for each component.
Continue studying — chapter 03 of 04
← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →