Chapter 8 — Application and software supply chain security: difficult cases
Lesson map
Lesson 08 published. Map, example, EX036.
flowchart TD
N0["Learning outcomes"]
N1["8.1 Vendor resistance"]
N2["8.2 Compromised upstream"]
N3["8.3 Incomplete information"]
N4["8.4 Conflicting priorities"]
N5["8.5 Escalation"]
N6["8.6 Learning"]
N7["Case library"]
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 Vendor resistance"]
N2["8.2 Compromised upstream"]
N3["8.3 Incomplete information"]
N4["8.4 Conflicting priorities"]
N5["8.5 Escalation"]
N6["8.6 Learning"]
N7["Case library"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX036"]
[Learning outcomes]
|
v
[8.1 Vendor resistance]
|
v
[8.2 Compromised upstream]
|
v
[8.3 Incomplete information]
|
v
[8.4 Conflicting priorities]
|
v
[8.5 Escalation]
|
v
[8.6 Learning]
|
v
[Case library]
|
v
[Worked example] --> [Exercise EX036]
Learning outcomes
You will (1) handle cases where good options conflict; (2) manage vendor resistance; (3) respond to a compromised upstream component; (4) make decisions with incomplete information.
8.1 Vendor resistance
A fraud-detection SDK vendor refuses to disclose which data its SDK collects, citing trade secrets. The SDK reduces fraud losses significantly. Options: accept with isolation, negotiate, or replace. Hannah negotiates a confidential data schedule shared with the bank's privacy team only, plus isolation of the SDK's inputs.
Hannah records why the bank accepted less transparency than its standard terms require: the fraud losses the SDK prevents are large and measurable, and isolation limits what it can reach. The exception has an expiry date, and the vendor is asked again at renewal.
8.2 Compromised upstream
An open-source library used by the web banking app is reported to have had a malicious version published for six hours after a maintainer's account was taken over, a pattern described by Ohm et al. (2020). Using SBOMs, the team confirms no Northbridge build included that version, because lockfile hashes pinned the previous version and updates are batched weekly.
The team posts its conclusion in the incident channel with the evidence attached: the SBOM entries, the lockfile hashes and the dates of the weekly batches. Hannah also checks whether any developer machine fetched the bad version directly, since lockfiles protect builds but not local experiments.
8.3 Incomplete information
Early reports are confused about which versions were affected. Hannah's rule: assume the wider range until confirmed, check builds against it, and update the assessment as facts emerge.
She writes each update with the time, what is confirmed and what is still assumed. The first assessment covered every version released that week, and it narrowed as the maintainers published details. Because each update says what it rests on, a later correction does not undermine trust in the earlier ones or in the team's final conclusion.
8.4 Conflicting priorities
A product launch depends on a new identity-verification SDK whose diff shows it sends device identifiers to a new destination. The vendor explains it is a fraud-prevention service. Privacy approves with a notice update; launch slips by three days.
The launch team was frustrated by the delay, but the diff had shown a real change that customers needed to be told about. The vendor's explanation was checked against its published documentation before privacy agreed. Hannah records the case to show the diff working under deadline pressure.
8.5 Escalation
When teams disagree, the CISO decides within two working days, with reasoning recorded.
The CISO hears both sides together, usually in a short call, and decides on the evidence in the diff and the register. The written decision states the reasoning, any conditions, and when it will be revisited. Recording reasons means a similar dispute later can be settled by pointing to the earlier decision. Teams may ask for a decision to be reviewed if new evidence appears, such as a vendor changing its documentation.
8.6 Learning
Each difficult case is written up as a short case study for training.
A case study is one page: what happened, what the team knew at each point, what they decided, and what they would do differently. The fraud-detection vendor, the compromised library and the delayed launch were the first three written up. Each is used in the mobile engineers' training sessions, and new joiners read them during onboarding. Hannah removes vendor names from the versions shared outside the security team.
Case library
The case studies are short and anonymised.
Worked example
In the compromised-library case, the team also checks build logs for any download of the malicious version during the six-hour window and finds none. They publish an internal note within four hours of the report, reassuring product owners and recording evidence.
Synthetic case. Cases are synthetic.
Errors and limits
Quick reassurance is valuable but must rest on evidence; say what was checked.
Exercises
- EX036 — Trade-secret vendor. How was the trade-secret vendor handled? Rubric: 3 = confidential data schedule to privacy; isolation; 2 = partial; 1 = vague; 0 = none.
- EX037 — Compromise check. How did the team know no build was affected? Rubric: 3 = SBOM, lockfile hashes pinned previous, weekly batching, logs; 2 = partial; 1 = vague; 0 = none.
- EX038 — Uncertain ranges. What is Hannah's rule for unclear version ranges? Rubric: 3 = assume wider range until confirmed; 2 = partial; 1 = vague; 0 = none.
- EX039 — Launch case. What happened with the identity SDK? Rubric: 3 = new destination; privacy approved with notice update; 3-day slip; 2 = partial; 1 = vague; 0 = none.
- EX040 — Escalation. How are disagreements resolved? Rubric: 3 = CISO decides within 2 days, reasoning recorded; 2 = partial; 1 = vague; 0 = none.
Synthesis
Difficult cases need evidence, staged assumptions, clear escalation and recorded reasoning.
Continue studying — chapter 08 of 12
← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →