Chapter 11 — Application and software supply chain security: assets and context
Lesson map
Lesson 11 published. Map, example, EX031.
flowchart TD
N0["Learning outcomes"]
N1["11.1 Data assets"]
N2["11.2 Supply chain assets"]
N3["11.3 Rating importance"]
N4["11.4 Owners"]
N5["11.5 Context records"]
N6["11.6 Using context"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX031"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["11.1 Data assets"]
N2["11.2 Supply chain assets"]
N3["11.3 Rating importance"]
N4["11.4 Owners"]
N5["11.5 Context records"]
N6["11.6 Using context"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]
[Learning outcomes]
|
v
[11.1 Data assets]
|
v
[11.2 Supply chain assets]
|
v
[11.3 Rating importance]
|
v
[11.4 Owners]
|
v
[11.5 Context records]
|
v
[11.6 Using context]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX031]
Learning outcomes
You will (1) list the assets in client apps and the supply chain; (2) rate their importance; (3) record owners and context; (4) use context to prioritise work.
11.1 Data assets
Greenleaf's booking site holds owners' names, phone numbers and emails, pet medical notes, uploaded X-rays and reports, and appointment histories. Medical notes and uploads are the most sensitive because they are private and hard to replace. The harbour-cafe site, by contrast, holds only table bookings with a name and phone number. The difference changes how Diego treats the same advisory in each project. A flaw in Greenleaf's upload feature could expose X-rays and medical notes that owners cannot easily replace, while the same flaw at harbour-cafe would expose names and phone numbers for table bookings. Both clients deserve a fix, but the Greenleaf fix comes first.
11.2 Supply chain assets
Code repositories, the library registry configuration, the build service, signing and deployment credentials, the image registry and the hosting accounts are all assets. A weakness in any of them could change every client's site at once, which makes them more important than any single client app. The build service alone touches all 23 client projects, so a change to its configuration reaches every site at the next deployment. Deployment credentials can put any image on any client's hosting. That reach is why these assets get Aiko's ownership and the strictest access rules in the agency.
11.3 Rating importance
Diego rates each asset high, medium or low using two questions: how much harm if it were exposed or changed, and how many clients depend on it. Deployment credentials score high on both; a single client's public image folder scores low. The two questions give a simple grid that every owner can apply consistently. Deployment credentials are high on harm and on client count. Greenleaf's upload bucket is high on harm but serves one client. A single client's public image folder is low on both, since its contents are already public and only one site uses it. Diego writes one line of reasoning beside each rating so others can challenge it.
11.4 Owners
Every asset has a named owner who decides about access and changes. The build service is owned by Aiko; each client app by its lead developer. Named owners are what made the four-minute test advisory possible: the inventory could say who should receive each alert. The build service's owner, Aiko, decides who may change pipeline settings, and each lead developer decides when a client's update is deployed. Where an owner leaves, the access review flags the gap and a new owner is named before the asset is left unwatched.
11.5 Context records
The inventory gains a short context note per project: data held, internet exposure, the client's contact for incidents, and any contract requirements such as response times. For Greenleaf the note records medical notes and uploads, a public booking form, the clinic manager as incident contact, and the contract's response time. For harbour-cafe it records only table bookings with a name and phone number. Diego keeps each note to a few lines so owners actually update it when a project changes.
11.6 Using context
When an advisory arrives, context decides the order of work: projects with sensitive data and public exposure come first. The order is applied even when every project will eventually be patched. During the form-library advisory, Greenleaf and museum-tickets were patched the same day, while three brochure sites with no forms in use waited for the weekly cycle. Writing the order down beforehand avoids arguing about priorities while an advisory is open. Exposure also counts: a site whose affected feature is not reachable from the internet can wait for the weekly cycle.
Worked example
Context changes the order of work during the next advisory, which affects a form library used by eight clients. Greenleaf and museum-tickets, holding medical notes and payment references, are patched the same day; the three small brochure sites with no forms in use are patched in the weekly cycle.
Synthetic case. Assets and ratings are synthetic.
Errors and limits
Ratings are judgements; record the reasoning so others can challenge them.
Exercises
- EX031 — Most sensitive. Which Greenleaf assets are most sensitive? Rubric: 3 = medical notes and uploads; 2 = one; 1 = vague; 0 = none.
- EX032 — Supply chain importance. Why do supply chain assets rate highly? Rubric: 3 = affect all clients at once; 2 = partial; 1 = vague; 0 = none.
- EX033 — Context order. How did context order the form-library patching? Rubric: 3 = sensitive same day; brochure sites weekly; 2 = partial; 1 = vague; 0 = none.
Synthesis
Know assets, owners and context so priorities follow real harm.
Continue studying — chapter 11 of 30
← Chapter 10 (draft) · Course chapter index · Chapter 12 (draft) →