Chapter 21 — Application and software supply chain security: service integration
Lesson map
Lesson 21 published. Map, example, EX061.
flowchart TD
N0["Learning outcomes"]
N1["21.1 External services"]
N2["21.2 Secrets for services"]
N3["21.3 Validating responses"]
N4["21.4 Least data"]
N5["21.5 Failure planning"]
N6["21.6 Reviewing services"]
N7["Service inventory"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX061"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["21.1 External services"]
N2["21.2 Secrets for services"]
N3["21.3 Validating responses"]
N4["21.4 Least data"]
N5["21.5 Failure planning"]
N6["21.6 Reviewing services"]
N7["Service inventory"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX061"]
[Learning outcomes]
|
v
[21.1 External services]
|
v
[21.2 Secrets for services]
|
v
[21.3 Validating responses]
|
v
[21.4 Least data]
|
v
[21.5 Failure planning]
|
v
[21.6 Reviewing services]
|
v
[Service inventory]
|
v
[Worked example] --> [Exercise EX061]
Learning outcomes
You will (1) secure connections to external services; (2) manage service secrets; (3) validate data from services; (4) plan for service failures.
21.1 External services
Client apps use an email service, a payment provider for museum-tickets and a mapping service for the kiteschool site. Each is a trust boundary: Brightwave depends on it and sends data to it. Each service receives some client data and returns answers the apps act on, so a problem at the provider can become a problem for the client. The email service sees owners' email addresses, the payment provider handles museum ticket payments and the mapping service receives requests from kiteschool-site visitors.
21.2 Secrets for services
Service keys are kept in the hosting platform's secret store, scoped to one client and one environment, and rotated yearly or immediately if exposed. Keys never appear in code; a pre-commit scan catches mistakes. Scoping a key to one client and one environment means a leaked test key cannot reach production, and a leaked kiteschool key cannot touch museum-tickets. Yearly rotation limits how long a quietly copied key stays useful, and immediate rotation is the response whenever a key appears in a log, a chat or a repository. The date of each rotation is recorded in the service inventory for later review.
21.3 Validating responses
Data returned by services is checked like user input. Payment confirmations are verified with the provider's signature before marking a ticket as paid. Without the signature check, anyone who learned the callback address could have sent a message claiming a ticket was paid. Other responses get the same treatment as form input: mapping results are checked for expected fields, and unexpected values are logged and rejected rather than shown to visitors. A provider's good reputation does not change this rule for any Brightwave integration.
21.4 Least data
Only needed data is sent: the email service receives the owner's email and appointment time, not medical notes. Medical notes stay inside Greenleaf's database because the email only needs to confirm a time. If the email provider ever had a breach, Greenleaf's exposure would be limited to addresses and appointment times. Diego checks each integration's outgoing fields against this rule and removes two unneeded fields from a confirmation template. Each service's data list is recorded in the service inventory so later changes can be compared against it.
21.5 Failure planning
If the email service fails, bookings still save and emails retry later; if payment confirmation is missing, the ticket stays pending. These rules keep a provider's outage from becoming a booking outage. Greenleaf's clinic still receives every booking when the email service is down, and confirmations are sent once it recovers. A museum ticket without a confirmed payment is never marked paid by default, so a missing callback cannot give away free entry. Each failure path has a synthetic test so the behaviour is checked on every build.
21.6 Reviewing services
Before adding a service, Brightwave reviews its security information and data location. The review records what data the service would receive, where it stores that data, how keys are issued and rotated, and how the provider announces security incidents. The answers go into the service inventory before any client data is sent. A service that cannot answer these questions is not added until a safer alternative or arrangement is found. Diego applies the same review retroactively to the three existing services and records the answers in the service inventory.
Service inventory
Diego adds external services to the inventory: which client uses which service, what data is sent, where the key is stored and when it was last rotated. When a provider announces a security incident, Brightwave can tell within minutes which clients are affected and which keys to rotate. During the year, the mapping provider announces a key-handling issue; the kiteschool key is rotated the same afternoon and the client informed.
Timeouts
Every service call has a timeout so a slow provider cannot freeze the booking site.
Worked example
Reviewing integrations, Diego finds the museum-tickets payment callback accepted confirmations without checking the provider's signature. Signature verification is added and tested with synthetic signed and unsigned messages.
Synthetic case. Services and findings are synthetic.
Errors and limits
A trusted provider can still send unexpected data; validate everything.
Exercises
- EX061 — Key storage. Where are service keys kept? Rubric: 3 = secret store, scoped per client and environment; 2 = partial; 1 = vague; 0 = none.
- EX062 — Least data. What does the email service receive? Rubric: 3 = email and appointment time only; 2 = partial; 1 = vague; 0 = none.
- EX063 — Callback finding. What was wrong with the payment callback? Rubric: 3 = no signature check; 2 = partial; 1 = vague; 0 = none.
Synthesis
Treat every service as a boundary to check.
Continue studying — chapter 21 of 30
← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →