Chapter 35 — Design studio II
Lesson map
Lesson 35 published. Map, example, EX103.
flowchart TD
N0["Learning outcomes"]
N1["35.1 The brief"]
N2["35.2 Vendor risk"]
N3["35.3 Technical isolation"]
N4["35.4 Contractual controls"]
N5["35.5 Monitoring"]
N6["35.6 Presentation"]
N7["Exit planning"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX103"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["35.1 The brief"]
N2["35.2 Vendor risk"]
N3["35.3 Technical isolation"]
N4["35.4 Contractual controls"]
N5["35.5 Monitoring"]
N6["35.6 Presentation"]
N7["Exit planning"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX103"]
[Learning outcomes]
|
v
[35.1 The brief]
|
v
[35.2 Vendor risk]
|
v
[35.3 Technical isolation]
|
v
[35.4 Contractual controls]
|
v
[35.5 Monitoring]
|
v
[35.6 Presentation]
|
v
[Exit planning]
|
v
[Worked example] --> [Exercise EX103]
Learning outcomes
You will (1) design a supply-chain improvement for a third-party integration; (2) evaluate vendor software risk; (3) specify contractual and technical controls; (4) present to stakeholders.
35.1 The brief
Coastline plans to add a vendor's journey-planning widget to ticket-web. Kwame's team must design how to integrate it safely.
Third-party scripts run with the same rights as Coastline's own code when included directly in a page, so a compromised vendor could read rider data or change ticket prices shown to users. The brief therefore asks for more than a feature integration. It asks the team to decide how much the widget should be able to reach, how Coastline would notice a malicious change, and how it could be removed quickly.
35.2 Vendor risk
Questions to the vendor: Do you follow the SSDF? Do you provide SBOMs and signed releases? How fast do you fix vulnerabilities? Do you have a disclosure process?
The answers show whether the vendor's practices resemble the controls Coastline applies to itself. A vendor that follows the SSDF and signs releases makes verification possible; one that cannot say how fast it fixes flaws leaves Coastline guessing. The team scores answers against a short rubric and asks for evidence, such as a published disclosure policy, rather than accepting yes or no.
35.3 Technical isolation
Options: include the vendor's script directly in ticket-web pages; host a pinned copy with an integrity hash; or load the widget in a sandboxed frame on a separate domain. The sandboxed frame limits the widget's access to rider data.
Direct inclusion is easiest but gives the vendor the most power, and the vendor can change the script at any time. A pinned copy with an integrity hash stops silent changes but still runs with full page access. The sandboxed frame keeps the widget in a separate origin, so browser rules stop it reading ticket-web's pages or cookies.
35.4 Contractual controls
The contract requires notification of security incidents within 48 hours, SBOM delivery with each release and fixing critical flaws within 14 days.
Each term gives Coastline something to act on. Notification within 48 hours lets the team check exposure before attackers spread. SBOMs feed the same advisory check used for Coastline's own components. The 14-day fix commitment sets an expectation the team can measure and raise with the vendor if missed. Terms are kept specific so both sides can tell whether they are met.
35.5 Monitoring
Coastline monitors the widget's domain and versions and alerts on unexpected changes.
Because the widget sits on the vendor's domain, Coastline cannot control its content. It can, however, watch for changes in the script's version, size or the hosts it contacts, and compare them with the vendor's announced releases. An unannounced change triggers a check with the vendor and, if unexplained, use of the exit plan to switch the widget off. Monitoring results are reviewed monthly during the pilot, with any surprises raised at the vendor meeting.
35.6 Presentation
The team presents to Ingrid, procurement and legal.
Each audience has different questions. Ingrid cares about isolation and verification; procurement asks about cost and the vendor's terms; legal asks about liability, audit rights and data handling. The team prepares one slide for each concern and keeps the technical detail in an appendix. Presenting to all three together lets disagreements surface early, such as legal wanting stronger audit rights than procurement expected to negotiate. Questions that cannot be answered on the spot are recorded with an owner and a date for a written reply.
Exit planning
The design also covers removal: if the vendor fails or the relationship ends, the widget can be turned off with a configuration change and the page still works without it. Riders see a simple link to a timetable page instead. Planning exit at the start avoids being locked into a risky supplier.
Stakeholder questions
Procurement asked about cost; the team showed that sandboxing added no licence fees and only two days of work.
Approval
Ingrid signs off the design for a three-month pilot.
Worked example
The team recommends the sandboxed frame with pinned versions plus contract terms. Legal adds a right to audit. The vendor agrees to provide SBOMs quarterly instead of per release; the team accepts this with monitoring as compensation.
Synthetic case. The vendor and terms are synthetic.
Errors and limits
Contracts help after incidents but do not prevent them; technical isolation is the first control.
Exercises
- EX103 — Vendor questions. List three vendor questions. Rubric: 3 = SSDF, SBOM/signing, fix speed, disclosure (three); 2 = two; 1 = one; 0 = none.
- EX104 — Isolation choice. Why choose a sandboxed frame? Rubric: 3 = limits widget access to rider data; 2 = partial; 1 = vague; 0 = none.
- EX105 — Negotiated outcome. What compromise was reached on SBOMs? Rubric: 3 = quarterly; monitoring compensates; 2 = partial; 1 = vague; 0 = none.
Synthesis
Third-party code needs technical isolation, contractual terms and monitoring.
Continue studying — chapter 35 of 50
← Chapter 34 (draft) · Course chapter index · Chapter 36 (draft) →