Chapter 20 — Application and software supply chain security: engineering context
Lesson map
Lesson 20 published. Map, example, EX058.
flowchart TD
N0["Learning outcomes"]
N1["20.1 The chain"]
N2["20.2 Attack classes"]
N3["20.3 Coastline's controls"]
N4["20.4 Standards"]
N5["20.5 Open source realities"]
N6["20.6 Engineering context"]
N7["Responsibility"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX058"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["20.1 The chain"]
N2["20.2 Attack classes"]
N3["20.3 Coastline's controls"]
N4["20.4 Standards"]
N5["20.5 Open source realities"]
N6["20.6 Engineering context"]
N7["Responsibility"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX058"]
[Learning outcomes]
|
v
[20.1 The chain]
|
v
[20.2 Attack classes]
|
v
[20.3 Coastline's controls]
|
v
[20.4 Standards]
|
v
[20.5 Open source realities]
|
v
[20.6 Engineering context]
|
v
[Responsibility]
|
v
[Worked example] --> [Exercise EX058]
Learning outcomes
You will (1) describe the software supply chain from source to user; (2) identify actors and stages; (3) relate known attack classes to stages; (4) place Coastline's controls on the chain.
20.1 The chain
Source code is written, reviewed and stored; dependencies are fetched; code is built; artifacts are stored and distributed; software is deployed and updated. Each stage has actors: developers, maintainers, registries, CI providers and operators.
Listing actors shows how many parties outside Coastline influence what riders run. Maintainers write the dependencies, registries host them, the CI provider runs the builds, and Coastline's operators deploy. Each handover is a point where something can be swapped or altered, which is why the controls later in this chapter are arranged by stage.
20.2 Attack classes
Ohm et al. (2020) and Ladisa et al. (2023) describe attacks such as malicious packages, compromised maintainer accounts, tampering with build systems and substituting artifacts during distribution. This course stays defensive: it uses these classes to decide where controls belong, not to describe how to carry attacks out.
Grouping attacks by the stage they target is more useful to defenders than listing individual incidents. A compromised maintainer account and a malicious lookalike package both arrive through dependencies, so the same mirror, name check and review controls apply. Build tampering needs different controls, such as isolated runners and provenance, because the source and dependencies may be perfectly clean.
20.3 Coastline's controls
Source: branch protection and review. Dependencies: lockfiles, name checks, mirror, advisory checks. Build: isolated hosted runners, pinned tools. Artifacts: signing, provenance, digest checks. Deployment: verification policy. Operation: monitoring and update process.
Laying controls along the chain shows where coverage is thin. Operation has the fewest controls, which reflects that monitoring a running app for signs of a tampered component is hard. Each listed control has an owner and a test, so the team can show it works rather than simply claiming it exists. Kwame's diagram in the worked example applies this check.
20.4 Standards
SLSA v1.0 describes build track levels with increasing provenance and isolation guarantees; the SSDF (SP 800-218) practice PS.2 asks producers to provide a way to verify release integrity; ASVS includes requirements on components and configuration.
The three standards look at different parts of the problem. SLSA focuses on how artifacts are built and how their origin can be shown. The SSDF covers the organisation's development practices as a whole. ASVS tests the application itself. Using them together avoids the trap of a well-built artifact containing a poorly secured application, or the reverse.
20.5 Open source realities
Wermke et al. (2022) found that open-source projects vary widely in security practices and rely heavily on trust in contributors. Consumers like Coastline cannot assume upstream controls exist.
Many projects depend on a handful of volunteers with no security budget. Coastline therefore treats upstream security as a variable to check, not a given: it looks at maintenance activity, use of multi-factor authentication where registries show it, and whether a project publishes signatures. Where Coastline relies heavily on a project, it can also contribute fixes or funding.
20.6 Engineering context
Supply chain security is an engineering problem: it requires requirements, design, measurement and verification like any other system property.
Treating it this way means stating measurable goals, such as every deployed artifact having verified provenance, designing controls to meet them, and testing that they hold. It also means accepting trade-offs: stronger controls cost build time and engineering effort, and the team chooses where they bring the most risk reduction. Calling it engineering rather than a checklist exercise keeps attention on whether controls work, not on whether they exist on paper. The rest of the course follows this pattern from requirements to verification.
Responsibility
Coastline names an owner for each stage of its chain, so every control has someone who maintains it.
Worked example
Kwame's chain diagram shows one gap: the mobile app's build is done on a developer's laptop, not CI. Coastline moves it to hosted CI within a month.
Synthetic case. Controls and gaps are synthetic.
Errors and limits
A chain diagram simplifies; real chains include tools, plugins and services not shown.
Exercises
- EX058 — Chain stages. List the stages of the software supply chain. Rubric: 3 = source, dependencies, build, artifacts, distribution, deployment/update; 2 = four; 1 = two; 0 = none.
- EX059 — SSDF PS.2. What does SSDF PS.2 ask? Rubric: 3 = way to verify release integrity; 2 = partial; 1 = vague; 0 = none.
- EX060 — Mobile gap. What gap did the diagram show? Rubric: 3 = mobile build on laptop; moved to CI; 2 = partial; 1 = vague; 0 = none.
Synthesis
Map the chain, its actors and controls, then engineer the gaps closed.
Continue studying — chapter 20 of 50
← Chapter 19 (draft) · Course chapter index · Chapter 21 (draft) →