Chapter 26 — Application and software supply chain security: architecture alternatives
Lesson map
Lesson 26 published. Map, example, EX076.
flowchart TD
N0["Learning outcomes"]
N1["26.1 The question"]
N2["26.2 Risk trade-offs"]
N3["26.3 Build options"]
N4["26.4 Reproducibility"]
N5["26.5 Usability"]
N6["26.6 Decision"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX076"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["26.1 The question"]
N2["26.2 Risk trade-offs"]
N3["26.3 Build options"]
N4["26.4 Reproducibility"]
N5["26.5 Usability"]
N6["26.6 Decision"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX076"]
[Learning outcomes]
|
v
[26.1 The question]
|
v
[26.2 Risk trade-offs]
|
v
[26.3 Build options]
|
v
[26.4 Reproducibility]
|
v
[26.5 Usability]
|
v
[26.6 Decision]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX076]
Learning outcomes
You will (1) compare architectural options for dependency management and build integrity; (2) evaluate trade-offs in cost, risk and usability; (3) use evidence from the literature to justify choices; (4) record decisions.
26.1 The question
How should ticket-web obtain dependencies? Option 1: fetch directly from the public registry with lockfile hashes. Option 2: an internal mirror that proxies and caches the registry. Option 3: a curated internal repository where each new package version is reviewed before use.
The three options represent increasing levels of control. Each moves the point where Coastline can inspect packages closer to its own boundary. The choice affects every build and every developer, so it is worth comparing carefully before committing. Kwame's team also asks which option a team of Coastline's size can keep running for years, not just set up.
26.2 Risk trade-offs
Option 1 is simple but depends on the registry's availability and offers no central control point. Option 2 adds caching, logging and a place for checks, with modest cost. Option 3 gives the most control but slows updates, which can lengthen exposure to known flaws; Kula et al. (2018) showed that update friction already causes lag, and Decan et al. (2018) showed how lag spreads vulnerabilities.
The tension is between control and speed. Every check added before a package can be used also delays the fixes that arrive as new versions, so tighter control can mean longer exposure. Option 2 sits in the middle: it inspects packages automatically as they pass through, without waiting for a person.
26.3 Build options
For builds: self-hosted runners give control but must be maintained and isolated; hosted runners from the CI provider offer fresh, isolated environments and platform-generated provenance aligned with SLSA v1.0 Build Level 2 and above, but depend on the provider.
Self-hosted runners require Coastline to patch, isolate and monitor them, which the old reused build agent showed is easy to get wrong. Hosted runners shift that work to the provider and produce provenance the build script cannot forge. The cost is dependence on the provider's availability and security, which Coastline checks through the provider's published assurances.
26.4 Reproducibility
Reproducible builds (Lamb and Zacchiroli, 2022) let an independent builder recreate the same bits, detecting tampering in the original build. Coastline evaluates making ticket-web's server build reproducible; it requires fixing timestamps and ordering in the build.
Timestamps embedded in files and the order in which files are archived are common reasons two builds of the same source differ. Fixing them lets an independent rebuild be compared with the release by digest. A match is strong evidence that the release came from the stated source. A mismatch is investigated before the release is trusted.
26.5 Usability
Developers need fast builds and simple upgrades. A design that slows them down will be worked around, echoing Johnson et al. (2013) on tool adoption.
Developers under deadline pressure find shortcuts: copying a package into the repository to avoid the mirror, or disabling a slow check. Each shortcut removes the control it avoided. Designs that are fast and simple to follow get used as intended, so usability is a security requirement, not a convenience. Coastline measures build times and the time to add a new dependency before and after each change to the design, and treats a significant slowdown as a defect to be fixed.
26.6 Decision
Coastline chooses option 2 with automatic checks (name similarity, advisories, licence), hosted runners, and a pilot of reproducible server builds.
The decision combines the option that balances control with update speed, a build platform that removes maintenance burden and provides provenance, and a limited pilot of reproducible builds to learn the cost before committing. The pilot covers only the server build, because the mobile build depends on store tooling that is harder to make reproducible. The record lists conditions that would reopen the choice, such as the registry suffering repeated outages or the curated option becoming cheaper through automation.
Worked example
Kwame's decision record compares the three options in a table of control, cost, update speed and availability. He estimates option 3 would add about 5 days to the median time to adopt a fix, unacceptable given the 7-day critical target.
Synthetic case. Options, estimates and decisions are synthetic.
Errors and limits
Architecture choices depend on organisation size; a small team may not sustain a curated repository.
Exercises
- EX076 — Option 3 cost. Why was the curated repository rejected? Rubric: 3 = slows updates; ~5 days; critical target; 2 = partial; 1 = vague; 0 = none.
- EX077 — Hosted runner benefit. What do hosted runners provide? Rubric: 3 = fresh isolated environments; platform provenance; 2 = partial; 1 = vague; 0 = none.
- EX078 — Reproducibility need. What does reproducibility require for ticket-web? Rubric: 3 = fix timestamps and ordering; 2 = partial; 1 = vague; 0 = none.
Synthesis
Choose architectures that balance control, update speed and usability, with recorded evidence.
Continue studying — chapter 26 of 50
← Chapter 25 (draft) · Course chapter index · Chapter 27 (draft) →