Chapter 2 — Application and software supply chain security: service and stakeholder context
Lesson map
Lesson 02 published. Map, example, EX006.
flowchart TD
N0["Learning outcomes"]
N1["2.1 The service"]
N2["2.2 Stakeholders"]
N3["2.3 Their priorities"]
N4["2.4 Agreeing ways of working"]
N5["2.5 The registry decision"]
N6["2.6 Stakeholder map"]
N7["Keeping stakeholders informed"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX006"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["2.1 The service"]
N2["2.2 Stakeholders"]
N3["2.3 Their priorities"]
N4["2.4 Agreeing ways of working"]
N5["2.5 The registry decision"]
N6["2.6 Stakeholder map"]
N7["Keeping stakeholders informed"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX006"]
[Learning outcomes]
|
v
[2.1 The service]
|
v
[2.2 Stakeholders]
|
v
[2.3 Their priorities]
|
v
[2.4 Agreeing ways of working]
|
v
[2.5 The registry decision]
|
v
[2.6 Stakeholder map]
|
v
[Keeping stakeholders informed]
|
v
[Worked example] --> [Exercise EX006]
Learning outcomes
You will (1) map TrackPort's users, data and dependencies; (2) identify stakeholders for supply chain decisions; (3) understand their priorities; (4) agree how to work together.
2.1 The service
TrackPort is a web and mobile application used by customers to track shipments and by depot staff to update them. It holds customer names, addresses and phone numbers, shipment contents and delivery photos. It depends on about 180 open-source packages and four internal packages. The four internal packages include hl-auth, hl-geo and hl-ledger, which are shared with other Harbourline applications. The data TrackPort holds makes any code in its build sensitive, whether from an open-source package or an internal one. Priya lists the packages and their sources before starting the review.
2.2 Stakeholders
The TrackPort developers own the code and fixes. The platform team runs the build service and the internal registry. Marcus's security team sets requirements. The product manager decides priorities. Depot managers need TrackPort available during shifts. Each stakeholder controls part of the fix: developers change TrackPort's code and lock files, the platform team changes registry settings, Marcus sets requirements and the product manager decides when work happens. Depot managers are affected by any outage caused by a change, so Priya keeps them informed about planned releases. She records these roles in the stakeholder map, so she knows whom to ask before a change touches the build service or a depot release.
2.3 Their priorities
Developers want few interruptions and clear findings; platform wants changes that apply to all teams; product wants features shipped; depots want no outages. A supply chain fix that ignores these will be resisted. Priya plans her approach around these priorities. Findings arrive checked and ranked, so developers spend little time on noise; the registry fix is proposed as one platform setting that protects every team; security work goes into normal sprint planning, so it competes fairly with features; and changes are released at times agreed with depot managers. Framing fixes this way makes it easier for each group to agree.
2.4 Agreeing ways of working
Priya agrees with the TrackPort lead that findings arrive as tickets with evidence and a suggested fix, high findings are discussed within a day, and security work fits into normal sprint planning. These agreements set expectations on both sides. Tickets with evidence mean developers do not have to repeat Priya's analysis, and a suggested fix gives them a starting point. Discussing high findings within a day means urgent issues are not left waiting for the next sprint. Fitting work into sprint planning lets the product manager see security work alongside features. The lead and Priya review the arrangement after the first month.
2.5 The registry decision
Who should decide how package sources are configured? The platform team, because one change protects every team using the build service. If each development team configured package sources separately, some would miss the rule and the hl-auth problem could recur elsewhere. The platform team runs the build service for every team, so a single setting there gives the same protection to all. Priya explains the finding to the platform team in terms of their priority: one change instead of many. They agree to change the configuration within two weeks.
2.6 Stakeholder map
A one-page map lists each stakeholder, what they need and how they are informed. The map includes the TrackPort developers, the platform team, Marcus's security team, the product manager and depot managers. For each, it records what they need from the project and how they hear about it: tickets for developers, a short meeting for the platform team, a fortnightly note for the product manager and release notices for depot managers. Priya updates the map when people change roles, as the late medium finding later showed is necessary.
Keeping stakeholders informed
A short monthly note to all stakeholders lists fixes made, open highs and decisions needed.
Worked example
In a short meeting, Priya explains the hl-auth finding to the platform team in terms of their priority: a single registry setting would stop internal names being taken from the public registry for every team. They agree to change the build service configuration within two weeks.
Synthetic case. People and systems are synthetic.
Errors and limits
Stakeholder priorities change; revisit the map each quarter.
Exercises
- EX006 — Data held. What data does TrackPort hold? Rubric: 3 = names, addresses, phones, contents, photos; 2 = three; 1 = one; 0 = none.
- EX007 — Fix owner. Who owns fixes in TrackPort code? Rubric: 3 = TrackPort developers; 2 = partial; 1 = vague; 0 = none.
- EX008 — Registry owner. Why does the platform team own the registry fix? Rubric: 3 = one change protects all teams; 2 = partial; 1 = vague; 0 = none.
- EX009 — Ways of working. What did Priya agree with the lead? Rubric: 3 = tickets with evidence; highs in a day; sprint planning; 2 = two; 1 = one; 0 = none.
- EX010 — Framing. How did Priya frame the finding for platform? Rubric: 3 = single setting protects all teams; 2 = partial; 1 = vague; 0 = none.
Synthesis
Know the service and speak to each stakeholder's priority.
Continue studying — chapter 02 of 12
← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →