Chapter 12 — Application and software supply chain security: data flows
Lesson map
Lesson 12 published. Map, example, EX034.
flowchart TD
N0["Learning outcomes"]
N1["12.1 Application flow"]
N2["12.2 Pipeline flow"]
N3["12.3 Trust boundaries"]
N4["12.4 Checks at boundaries"]
N5["12.5 Keeping current"]
N6["12.6 Common surprises"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX034"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["12.1 Application flow"]
N2["12.2 Pipeline flow"]
N3["12.3 Trust boundaries"]
N4["12.4 Checks at boundaries"]
N5["12.5 Keeping current"]
N6["12.6 Common surprises"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX034"]
[Learning outcomes]
|
v
[12.1 Application flow]
|
v
[12.2 Pipeline flow]
|
v
[12.3 Trust boundaries]
|
v
[12.4 Checks at boundaries]
|
v
[12.5 Keeping current]
|
v
[12.6 Common surprises]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX034]
Learning outcomes
You will (1) draw data flows for a client app and the build pipeline; (2) mark trust boundaries; (3) find where checks are needed; (4) keep diagrams current.
12.1 Application flow
For Greenleaf: the visitor's browser sends a booking form and an upload to the web app; the app checks it, stores the booking in the database and the file in the upload bucket; staff view bookings through the admin pages; the app sends a confirmation through the email service. Each arrow on the diagram names the data it carries: owner details and pet notes, uploaded files, bookings to the admin pages, and only email address and appointment time to the email service.
12.2 Pipeline flow
A developer pushes code; the build service fetches code and libraries, runs tests and checks, builds an image, pushes it to the registry, and the deployment step pulls the image onto hosting. Secrets are injected only at deployment. The flow shows where upload-kit entered: at the step where the build service fetched libraries. Secrets entering only at deployment means a build that runs tests on a pull request never holds a production key, so a mistaken or harmful change cannot read one during testing.
12.3 Trust boundaries
Marked boundaries: browser to app, app to database and bucket, app to email service, public library registry to build, build to registry, registry to hosting. Shostack (2014) recommends drawing such diagrams as the starting point for asking what can go wrong. Diego draws the two flows on one page so that the library registry, an outside party, appears as clearly as the visitor's browser. Each boundary is a place where one party hands data or code to another that should not simply trust it. The visitor may send a harmful file, the registry may serve a flawed library, and the registry-to-hosting step may receive an image nobody approved. Naming these handovers is what lets the next step assign a check to each.
12.4 Checks at boundaries
Each boundary needs a check: validation and size limits for uploads; least-privilege database accounts; pinned and verified libraries entering the build; recorded digests for images entering hosting. For Greenleaf, the upload boundary uses the type, content and size checks built later in the course. The registry-to-build boundary uses lockfile hashes and the audit against advisories. The registry-to-hosting boundary uses the approved-image rule, which refuses any digest that the main-branch build did not produce. A boundary without one of these checks is listed as a gap for the next review.
12.5 Keeping current
Diagrams live in each repository and are updated in the same pull request that changes a flow. Reviewers ask "does the diagram still match?" when a change adds a service. Keeping the diagram in the same pull request means reviewers see the change to the flow beside the change to the code. When Brightwave later adds the mapping service for kiteschool-site, the diagram gains an arrow and a boundary in the same review, along with a note of what data goes to the provider.
12.6 Common surprises
Drawing flows often reveals forgotten paths, such as an old export feature or a test webhook still enabled. At Greenleaf, the forgotten path was an old CSV export that any logged-in staff account could reach. It had worked for years without anyone thinking about who used it. Diego now asks owners, for every client diagram, to list features nobody has used recently, because those are the paths most likely to have been left without a check. Test webhooks left enabled after a launch are another common example the team now checks for.
Worked example
Drawing the Greenleaf flow reveals a forgotten path: an old CSV export endpoint that lists all bookings, reachable by any logged-in staff account including receptionists. It is restricted to managers and its use logged.
Synthetic case. Flows are synthetic.
Errors and limits
A diagram is a model; walk through the running system to check it.
Exercises
- EX034 — Pipeline entry. Where do libraries enter the pipeline? Rubric: 3 = public registry to build boundary; 2 = partial; 1 = vague; 0 = none.
- EX035 — Upload check. What check guards the upload boundary? Rubric: 3 = validation and size limits; 2 = partial; 1 = vague; 0 = none.
- EX036 — Forgotten path. What did the Greenleaf diagram reveal? Rubric: 3 = CSV export reachable by any staff; 2 = partial; 1 = vague; 0 = none.
Synthesis
Draw flows, mark boundaries and put a check on each.
Continue studying — chapter 12 of 30
← Chapter 11 (draft) · Course chapter index · Chapter 13 (draft) →