Chapter 21 — Application and software supply chain security: system models
Lesson map
Lesson 21 published. Map, example, EX061.
flowchart TD
N0["Learning outcomes"]
N1["21.1 Data flow diagrams"]
N2["21.2 Trust boundaries"]
N3["21.3 STRIDE"]
N4["21.4 Example threats"]
N5["21.5 Prioritising"]
N6["21.6 Four questions"]
N7["21.7 Keeping it small"]
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 Data flow diagrams"]
N2["21.2 Trust boundaries"]
N3["21.3 STRIDE"]
N4["21.4 Example threats"]
N5["21.5 Prioritising"]
N6["21.6 Four questions"]
N7["21.7 Keeping it small"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX061"]
[Learning outcomes]
|
v
[21.1 Data flow diagrams]
|
v
[21.2 Trust boundaries]
|
v
[21.3 STRIDE]
|
v
[21.4 Example threats]
|
v
[21.5 Prioritising]
|
v
[21.6 Four questions]
|
v
[21.7 Keeping it small]
|
v
[Worked example] --> [Exercise EX061]
Learning outcomes
You will (1) draw a data flow diagram for an application and its pipeline; (2) mark trust boundaries; (3) apply STRIDE to elements; (4) prioritise threats for a small project.
21.1 Data flow diagrams
Shostack (2014) recommends simple data flow diagrams for threat modelling: external entities (students, payment provider, package registry), processes (web app, build service), data stores (database, artifact store) and data flows between them. Lena draws CampusEats on one page.
Keeping it to one page forces choices about detail, and that makes the diagram usable in a short meeting. The build service and artifact store appear alongside the web app, because supply-chain threats need the build path on the same picture as the runtime path.
21.2 Trust boundaries
She draws dashed lines where trust changes: between students' browsers and the web app, between the web app and the payment provider, between the build service and the public registry, and between the build service and production.
Each boundary is a place where the receiving side must check what it gets, and Lena labels each dashed line with that check. Some boundaries are easy to forget. The one between the build service and production matters as much as the public one, because whatever the build produces is trusted by the live service. Lena checks each line with the person who owns it.
21.3 STRIDE
For each element, the team asks Shostack's STRIDE questions: could someone Spoof an identity, Tamper with data, Repudiate an action, cause Information disclosure, Deny service, or Elevate privilege?
The questions are asked in turn, and answers are written beside the element. Not every question applies everywhere, but asking all six avoids missing a category because nobody thought of it. Lena keeps answers short and specific to CampusEats, naming the data or action at risk rather than repeating the category name.
21.4 Example threats
Spoofing: a forged payment callback (fixed in chapter 17). Tampering: a package altered in transit (lockfile hashes, chapter 22). Information disclosure: secrets in the repository (scanning). Elevation: a volunteer reaching staff functions (role checks). Denial: lunchtime traffic spikes (rate limits and caching).
Each threat has a named control and a test, so the model links directly to the code and the build. Repudiation is covered by logs of staff actions, which let the society show who changed a price or issued a refund. Lena marks threats without a control in a different colour.
21.5 Prioritising
Each threat is rated low, medium or high for likelihood and impact. High-high items must have a control and a test.
Medium items get a control when it is cheap, otherwise a note and a date to revisit. Low items are recorded but not acted on. Ratings are agreed in the session by the people who know each part, and Lena notes when the group disagreed, since disagreement often means the risk is poorly understood and needs more evidence before a decision.
21.6 Four questions
Shostack's four questions frame the session: what are we working on, what can go wrong, what are we going to do about it, did we do a good job?
The last question is the one teams often skip. Lena answers it by checking at the next session whether the controls agreed last time were built and tested, and whether any incident since then involved a threat the model missed. That turns the model from a one-time document into a record the society can learn from.
21.7 Keeping it small
A one-hour session each term keeps the model current without burdening volunteers.
Lena prepares the diagram beforehand, shows only what changed since the last session and keeps a list of decisions. If a major change is planned, such as a new payment provider, an extra session is held for that change alone. Short, regular sessions have kept attendance steady, which matters more than any single detailed model. New members attend one session in their first term, which is also a quick way to learn how CampusEats fits together.
Worked example
The session finds a missed flow: the build service sends build logs to a third-party chat channel. Logs could contain environment values. The team configures masking of secret values in logs and restricts the chat channel to members.
Synthetic case. The model and threats are synthetic.
Errors and limits
Threat models depend on the people in the room; invite someone from outside the team.
Exercises
- EX061 — DFD elements. List the four kinds of DFD element with a CampusEats example each. Rubric: 3 = entity: students; process: web app; store: database; flow: callback; 2 = three; 1 = one; 0 = none.
- EX062 — STRIDE example. Give one STRIDE threat and its control. Rubric: 3 = e.g. spoofed callback: HMAC verification; 2 = partial; 1 = vague; 0 = none.
- EX063 — Missed flow. What missed flow did the session find? Rubric: 3 = build logs to chat; masking and restriction; 2 = partial; 1 = vague; 0 = none.
Synthesis
A one-page model and STRIDE questions find threats a busy team would miss.
Continue studying — chapter 21 of 40
← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →