◇ OpenCyber Academy
Doctoral research · Chapter 2 · English

Chapter 2 — Application and software supply chain security: research frontier

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 2 — Application and software supply chain security: research frontier

Lesson map

Lesson 02 published. Map, example, EX008.

flowchart TD
  N0["Learning outcomes"]
  N1["2.1 Attack taxonomies"]
  N2["2.2 Ecosystem studies"]
  N3["2.3 Integrity frameworks"]
  N4["2.4 Process standards"]
  N5["2.5 Prioritisation research"]
  N6["2.6 The gap"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX008"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["2.1 Attack taxonomies"]
  N2["2.2 Ecosystem studies"]
  N3["2.3 Integrity frameworks"]
  N4["2.4 Process standards"]
  N5["2.5 Prioritisation research"]
  N6["2.6 The gap"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX008"]
[Learning outcomes]
    |
    v
[2.1 Attack taxonomies]
    |
    v
[2.2 Ecosystem studies]
    |
    v
[2.3 Integrity frameworks]
    |
    v
[2.4 Process standards]
    |
    v
[2.5 Prioritisation research]
    |
    v
[2.6 The gap]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX008]

Learning outcomes

You will (1) map the current research frontier in software supply chain security; (2) use attack taxonomies to place a study; (3) connect standards to open research problems; (4) identify a defensible gap.

2.1 Attack taxonomies

Ohm et al. (2020) reviewed real malicious packages and showed how attackers abuse install scripts, typosquatting and account takeover. Ladisa et al. (2023) built a taxonomy of attacks on open-source supply chains covering source, build, distribution and dependency stages, mapped to safeguards. Yusuf uses the taxonomy to state that his thesis concerns a defensive question about known vulnerabilities, not malicious code. Placing the thesis on the taxonomy makes its scope visible: it studies the dependency stage after a fix is published, where the threat is a known flaw left in place, not an attacker inserting code. Examiners can then judge the claims against that stage alone. The taxonomy also reminds him that update bots are themselves tools in the dependency path.

2.2 Ecosystem studies

Zimmermann et al. (2019) showed that a few maintainer accounts in npm can reach a large share of packages, so risk concentrates. Decan et al. (2018) quantified vulnerability propagation. These studies motivate measuring whole dependency graphs, not single packages. For the larch registry, these findings mean that quillog's fix matters only as far as it propagates through dependents, many of them indirect. Yusuf therefore measures exposure at the level of each dependent project and records whether quillog is a direct or transitive dependency, which later matters for the pinned-transitive explanation in H2.

2.3 Integrity frameworks

SLSA v1.0 (OpenSSF, 2023) defines build provenance levels; in-toto (Torres-Arias et al., 2019) records each supply-chain step; Sigstore (Newman et al., 2022) makes signing easy; reproducible builds (Lamb and Zacchiroli, 2022) let anyone verify a binary. Thompson's "Reflections on Trusting Trust" (1984) is the classic reminder that tools themselves can be subverted. These frameworks protect the integrity of what is built and shipped; they do not measure how quickly a fixed version reaches dependents. Yusuf cites them to show where his question sits beside them: a project can have strong provenance and still run a vulnerable quillog version for months. His findings complement these controls rather than compete with them.

2.4 Process standards

NIST SP 800-218, the SSDF (Souppaya et al., 2022), asks producers to respond to vulnerabilities in their components; it does not say how fast is achievable. That is a gap Yusuf's evidence can inform. For Larchwood, the gap is practical: the foundation can tell maintainers to remediate component vulnerabilities, but it has no evidence on how much an update bot shortens the delay, or what else is needed. Yusuf's results are meant to supply that evidence for RV.2, with the limits stated so the foundation does not quote a figure beyond its conditions.

2.5 Prioritisation research

EPSS (Jacobs et al., 2021) estimates the probability that a vulnerability will be exploited, which could weight exposure days by real risk. Yusuf uses EPSS only as a sensitivity analysis: weighting exposure days by exploitation probability tests whether the main result depends on a few low-risk advisories. Prof. Okafor suggested this check during the main study, and it is reported as a robustness result, not as a new outcome. The unweighted median stays the pre-registered measure. Scores are taken from the date each advisory was published.

2.6 The gap

Little evidence compares exposure with and without update tooling while explaining the human reasons for lag. Yusuf's gap statement names both halves. The first half is a measurement question that registry data can answer; the second is an explanation question that only maintainers can answer. A study that did only one would leave Larchwood either with a number it cannot act on or with reasons it cannot size. Naming both halves in the gap statement commits Yusuf to the mixed design.

Worked example

Yusuf builds a matrix: rows are studies, columns are stage (taxonomy), method, data and limitation. Three cells reveal his niche: update-tooling effects are mostly reported in industry blogs, not peer-reviewed comparisons, and none link to maintainer explanations.

Synthetic case. The matrix entries about Yusuf's niche are synthetic; cited works are real.

Errors and limits

A gap claim is only as good as the search; document databases, terms and dates.

Exercises

Synthesis

Place the study within taxonomies, frameworks and evidence, then state a documented gap.

Continue studying — chapter 02 of 08

← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →