Chapter 22 — Application and software supply chain security: system and data models
Lesson map
Lesson 22 published. Map, example, EX064.
flowchart TD
N0["Learning outcomes"]
N1["22.1 Data flow diagrams"]
N2["22.2 Trust boundaries"]
N3["22.3 Software as data"]
N4["22.4 Linking models"]
N5["22.5 Model upkeep"]
N6["22.6 Simplicity"]
N7["Verifying flows"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX064"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["22.1 Data flow diagrams"]
N2["22.2 Trust boundaries"]
N3["22.3 Software as data"]
N4["22.4 Linking models"]
N5["22.5 Model upkeep"]
N6["22.6 Simplicity"]
N7["Verifying flows"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX064"]
[Learning outcomes]
|
v
[22.1 Data flow diagrams]
|
v
[22.2 Trust boundaries]
|
v
[22.3 Software as data]
|
v
[22.4 Linking models]
|
v
[22.5 Model upkeep]
|
v
[22.6 Simplicity]
|
v
[Verifying flows]
|
v
[Worked example] --> [Exercise EX064]
Learning outcomes
You will (1) model the application and pipeline as data flows; (2) identify trust boundaries on the model; (3) model the data that describes software (SBOM, provenance); (4) keep models current.
22.1 Data flow diagrams
Shostack (2014) recommends data flow diagrams for threat modelling: external entities, processes, data stores and flows, with trust boundaries drawn across flows. Kwame draws ticket-web: rider browser, web app, database, payment provider; and the pipeline: developer, repository, CI, mirror, artifact store, deployment.
The four element types make the diagram easy to read and to analyse systematically, because each type suggests particular questions. Data stores invite questions about who can read and change them; processes about what input they accept; external entities about how much they can be trusted.
22.2 Trust boundaries
Boundaries appear between rider and web app, web app and payment provider, CI and public registry, CI and production. Every flow crossing a boundary is a place to ask what could go wrong.
On the diagram, a boundary is a dashed line, and every flow that crosses it is checked for authentication, integrity and what happens if the other side misbehaves. The CI-to-registry crossing is where hash checks and the mirror apply; the CI-to-production crossing is where signature and provenance checks apply.
22.3 Software as data
An SBOM lists components and versions; NTIA (2021) defined minimum elements: supplier, component name, version, unique identifiers, dependency relationship, author of SBOM data and timestamp. Provenance records how an artifact was built. These are data models the pipeline produces and consumes.
Treating these records as data means they need the same care as other data: correct formats, validation, storage and access control. An SBOM that names the wrong version misleads the advisory check. Missing timestamps or authors make it impossible to tell how fresh the list is or who to ask about it.
22.4 Linking models
Each deployed artifact links to its SBOM and provenance by digest. Given a running server, the team can find exactly which components it contains.
The digest is the key that joins everything. From a running server, the team reads the artifact digest, finds the SBOM listing its components and the provenance naming the source commit and build. When an advisory names a component, the same links run backwards to every artifact and server containing it. Without these links, answering 'are we affected?' means searching by hand under pressure. Kwame tests the links each quarter by picking a random production server and tracing it back to source in under ten minutes.
22.5 Model upkeep
Models are stored with the code and updated in the same pull request as architecture changes.
Keeping models in the repository means changes are reviewed like code, and the history shows when each flow was added or removed. A reviewer who sees a new external call in the code but no matching change to the diagram asks for it. Outdated models are worse than none, because they give false confidence about which flows exist. Kwame adds a pull-request template question asking whether the change adds or removes a flow, so authors think about the model while the change is fresh.
22.6 Simplicity
Models should be just detailed enough to support decisions; a diagram nobody can read helps nobody.
A diagram covering every library call is unreadable and never kept current. Kwame's version shows a dozen processes and stores; detail goes into separate diagrams for areas that need it, such as payment handling. The test is whether a new engineer can explain the main flows after five minutes with the diagram. If a decision would not change with more detail, the detail is left out.
Verifying flows
Kwame compares the diagram with network logs from the build environment, confirming each logged connection appears in the model.
Model ownership
Ingrid's team owns the models and reviews them every quarter.
Worked example
The data flow diagram shows a flow Kwame had missed: CI sends build logs to a third-party log service. Logs may contain environment details. The team reviews log content and masks sensitive values.
Synthetic case. Diagrams and flows are synthetic.
Errors and limits
Diagrams describe intended behaviour; actual flows must be verified with network and configuration evidence.
Exercises
- EX064 — DFD elements. Name the four DFD element types. Rubric: 3 = external entities, processes, data stores, flows; 2 = three; 1 = one; 0 = none.
- EX065 — NTIA elements. List four NTIA SBOM minimum elements. Rubric: 3 = supplier, name, version, identifiers, relationship, author, timestamp (four); 2 = two; 1 = one; 0 = none.
- EX066 — Missed flow. What flow was missed and fixed? Rubric: 3 = CI logs to third-party service; masked values; 2 = partial; 1 = vague; 0 = none.
Synthesis
Model flows, boundaries and software metadata, and keep the models current.
Continue studying — chapter 22 of 50
← Chapter 21 (draft) · Course chapter index · Chapter 23 (draft) →