◇ OpenCyber Academy
Professional · Chapter 8 · English

Chapter 8 — Application and software supply chain security: supervised case analysis

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 8 — Application and software supply chain security: supervised case analysis

Lesson map

Lesson 08 published. Map, example, EX036.

flowchart TD
  N0["Learning outcomes"]
  N1["8.1 The case"]
  N2["8.2 Timeline"]
  N3["8.3 Causes"]
  N4["8.4 Missed signals"]
  N5["8.5 Recommendations"]
  N6["8.6 Proportion"]
  N7["Interviewing the team"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX036"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["8.1 The case"]
  N2["8.2 Timeline"]
  N3["8.3 Causes"]
  N4["8.4 Missed signals"]
  N5["8.5 Recommendations"]
  N6["8.6 Proportion"]
  N7["Interviewing the team"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX036"]

[Learning outcomes]
    |
    v
[8.1 The case]
    |
    v
[8.2 Timeline]
    |
    v
[8.3 Causes]
    |
    v
[8.4 Missed signals]
    |
    v
[8.5 Recommendations]
    |
    v
[8.6 Proportion]
    |
    v
[Interviewing the team]
    |
    v
[Worked example] --> [Exercise EX036]

Learning outcomes

You will (1) analyse a supply chain case under supervision; (2) build a timeline; (3) identify causes and missed signals; (4) recommend proportionate changes.

8.1 The case

Marcus asks Priya to analyse a synthetic case from another Harbourline team: a mobile app release included an analytics library update that began collecting device identifiers the privacy notice did not mention. The case is relevant because the same kind of dependency update happens in TrackPort every week. The library was not harmful in the usual sense, but it changed what the app did with customers' device data without anyone noticing. Priya's task is to explain how this happened and recommend changes that would catch similar updates without slowing the team.

8.2 Timeline

Day 0 the update was merged with a lock file change of 400 lines; day 3 released; day 20 a customer asked about data collection; day 22 the library was rolled back. The timeline shows that the change was released three days after merging and ran for nearly three weeks before a customer noticed. Rolling it back took two days once the question arrived. Priya lists each step with its source, such as the merge record and release log. The mobile team confirms each date from its merge and release records, so the timeline rests on evidence rather than memory.

8.3 Causes

The update was bundled with dozens of other changes, so reviewers did not notice a new data collection feature. There was no rule requiring privacy review for analytics libraries. The causes lie in the process, not in one reviewer's attention. A 400-line lock file change hides individual updates, and without a rule for analytics libraries, nobody thought to ask whether data collection had changed. Priya describes both causes without naming the developer or reviewer, since anyone could have missed the change under the same process.

8.4 Missed signals

The library's release notes mentioned the new collection feature; nobody read them because updates were routine. The information needed to catch the change was public all along. Release notes for most updates contain only fixes, so reading them seemed unnecessary. For analytics and advertising libraries, however, a new feature can mean new data collection. Priya recommends reading release notes for those libraries only, which is a small, targeted change. The mobile team agrees, and adds a short checklist of the libraries this applies to.

8.5 Recommendations

Separate pull requests for analytics and advertising libraries; release-note reading for those libraries; a privacy check in the release checklist. Each recommendation addresses a cause. Separate pull requests make analytics updates visible instead of hiding them among others. Reading release notes for those libraries catches new features. A privacy check in the release checklist gives a final chance to ask whether data collection changed. The mobile team adopts all three, and Priya records them in the case report. Each recommendation has a named owner in the mobile team and a date for the first check that it is being followed.

8.6 Proportion

The recommendations add minutes to a few updates rather than slowing all updates. Marcus asked Priya to remove a recommendation that would have required security sign-off for every update; it would have slowed all work to address a risk in a few libraries. The remaining recommendations apply only to analytics and advertising libraries. This proportion is why the mobile team accepted them, and why they are likely to be followed. The team reviews them after three months to check that they still fit.

Interviewing the team

Priya talks to the mobile developers and reviewer involved, asking what they saw and what they would have needed to notice the change. The conversations are framed around the process, and people speak openly. Their main point is that the 400-line lock file change gave no hint of which library mattered; a short summary of updated libraries in the pull request would have helped. This becomes a fourth, lightweight improvement: the update bot now lists changed libraries at the top of each pull request.

Worked example

Marcus reviews Priya's analysis and asks her to cut one recommendation that would have required security sign-off for every update. She agrees it was disproportionate, and the final report keeps the three targeted changes, which the mobile team adopts.

Synthetic case. The case is synthetic.

Errors and limits

Hindsight makes signals look obvious; judge decisions by what was knowable at the time.

Exercises

Synthesis

Analyse cases fairly and recommend proportionate changes.

Continue studying — chapter 08 of 12

← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →