Chapter 6 — Application and software supply chain security: system model
Lesson map
Lesson 06 published. Map, example, EX021.
flowchart TD
N0["Learning outcomes"]
N1["6.1 The model"]
N2["6.2 Checks on the model"]
N3["6.3 Producer practices"]
N4["6.4 Consumer practices"]
N5["6.5 Using the model"]
N6["6.6 Gaps found"]
N7["Model for updates"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX021"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["6.1 The model"]
N2["6.2 Checks on the model"]
N3["6.3 Producer practices"]
N4["6.4 Consumer practices"]
N5["6.5 Using the model"]
N6["6.6 Gaps found"]
N7["Model for updates"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX021"]
[Learning outcomes]
|
v
[6.1 The model]
|
v
[6.2 Checks on the model]
|
v
[6.3 Producer practices]
|
v
[6.4 Consumer practices]
|
v
[6.5 Using the model]
|
v
[6.6 Gaps found]
|
v
[Model for updates]
|
v
[Worked example] --> [Exercise EX021]
Learning outcomes
You will (1) model a customer site's supply chain from vendor to running site; (2) mark where checks belong; (3) compare to SSDF and SLSA ideas; (4) use the model in support work.
6.1 The model
Vendor writes plugin → vendor builds and publishes release with hash → download source (vendor site, registry or mirror) → Pinecrest support downloads → verification → installation on site → updates over time. Each arrow is a place where the software could change. At Ferncroft, the change happened at the download source arrow: the mirror served a modified copy. The vendor's release and hash were fine, but nobody compared them. Drawing the arrows lets support see that a check at the verification step would have caught the problem before installation.
6.2 Checks on the model
At download: use official sources. At verification: compare trusted hash or signature. At installation: correct permissions. Over time: track versions against advisories and watch for unexpected changes. Applied to Ferncroft, each check matches one gap: the mirror was not an official source, nothing was verified, the code folder was writable, and no inventory existed to track the plugin over time. The model turns a single incident into four separate controls, each owned and checked later in the course. Each check later gains its own verification test, scheduled in Tomás's calendar.
6.3 Producer practices
The SSDF asks producers to protect code and publish integrity information; SLSA v1.0 build levels describe provenance, a record of how a release was built. When vendors provide these, consumers can verify more. Pinecrest does not build plugins, so these practices describe what it can hope to receive from vendors. A published hash, as the resize plugin's vendor provided, is the simplest form. Signatures and provenance records go further, which is why the next steps in Chapter 18 include vendor signature checks.
6.4 Consumer practices
Pinecrest cannot change how vendors build, but it can prefer vendors that publish hashes or signatures and keep an inventory of what is installed where. The inventory is the consumer's main tool, because Pinecrest cannot react to an advisory about a plugin it does not know it runs. Preferring verifiable vendors costs little when customers ask for a plugin, since support can suggest an equivalent with published hashes when two plugins do the same job. These two consumer practices cost little and apply to every customer site Pinecrest hosts.
6.5 Using the model
Support uses the model when customers ask for plugins: is the source official, can it be verified, who updates it. For each request, support asks where the official download is, whether a hash or signature is published, and who will apply updates. A plugin that fails these questions is not automatically refused, but the customer is told the risk and the reason is recorded. The Ferncroft resize plugin would have passed if downloaded officially. The answers go into the installation ticket, so later reviews can see why a plugin was accepted.
6.6 Gaps found
The model shows Pinecrest had no inventory of plugins across customers. Without an inventory, nobody could say which other sites ran the resize plugin, or which version, when the Ferncroft case came to light. That gap made the case harder to scope and is why the nightly inventory becomes the centre of the later chapters, starting with Chapter 9. Scoping the Ferncroft case therefore relied on asking customers one by one, which is slow and incomplete across hundreds of hosted sites.
Model for updates
Updates follow the same path as first installations, so they need the same checks. Automatic plugin updates from the vendor's official channel are acceptable when that channel verifies integrity; manual updates repeat the hash check. The model also reminds support that removing unused plugins removes whole paths from the chain.
Worked example
Using the model, Grace and Tomás list the Ferncroft gaps: unofficial source, no verification, writable code folder, no inventory. Each becomes a control in later chapters.
Synthetic case. The model is synthetic.
Errors and limits
A model is only useful if updated when processes change.
Exercises
- EX021 — Model steps. List the model's steps. Rubric: 3 = vendor, publish, source, download, verify, install, update; 2 = four; 1 = two; 0 = none.
- EX022 — Download check. What check belongs at download? Rubric: 3 = official sources; 2 = partial; 1 = vague; 0 = none.
- EX023 — Consumer role. What can Pinecrest do as a consumer? Rubric: 3 = prefer verifiable vendors; inventory; 2 = partial; 1 = vague; 0 = none.
- EX024 — Four gaps. Name the four Ferncroft gaps. Rubric: 3 = unofficial source, no verification, writable folder, no inventory; 2 = three; 1 = one; 0 = none.
Synthesis
Model the chain and place a check on each step.
Continue studying — chapter 06 of 18
← Chapter 05 (draft) · Course chapter index · Chapter 07 (draft) →