OpenCyber Academy
Bachelor's · Chapter 20 · English
Course code: OCA-106Chapter 20: OCA-106-C020

Chapter 20 — Application and software supply chain security: foundational cases

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

Lesson map

Lesson 20 published. Map, example, EX058.

flowchart TD
  N0["Learning outcomes"]
  N1["20.1 Why cases"]
  N2["20.2 Malicious packages"]
  N3["20.3 Vulnerable dependencies"]
  N4["20.4 Build and distribution"]
  N5["20.5 Trust in open source"]
  N6["20.6 CampusEats lessons"]
  N7["Updating the cards"]
  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 Why cases"]
  N2["20.2 Malicious packages"]
  N3["20.3 Vulnerable dependencies"]
  N4["20.4 Build and distribution"]
  N5["20.5 Trust in open source"]
  N6["20.6 CampusEats lessons"]
  N7["Updating the cards"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX058"]

[Learning outcomes]
    |
    v
[20.1 Why cases]
    |
    v
[20.2 Malicious packages]
    |
    v
[20.3 Vulnerable dependencies]
    |
    v
[20.4 Build and distribution]
    |
    v
[20.5 Trust in open source]
    |
    v
[20.6 CampusEats lessons]
    |
    v
[Updating the cards]
    |
    v
[Worked example] --> [Exercise EX058]

Learning outcomes

You will (1) learn from published supply-chain cases at a conceptual level; (2) classify cases by stage; (3) extract defensive lessons; (4) apply lessons to a small project.

20.1 Why cases

Real cases show how failures happen in practice. This chapter uses published research summaries, describing what went wrong and what controls help, without technical details of attacks.

Each case below follows the same pattern: a published source, what it found and a lesson for a small project. Lena keeps the lessons practical, since the society's question is always what it should change. The cases also show that most supply-chain failures are not exotic: they exploit ordinary habits such as installing packages without looking at them, trusting a familiar name or postponing updates.

20.2 Malicious packages

Ohm et al. (2020) collected hundreds of malicious packages from public registries. Common patterns included lookalike names, packages that ran code during installation, and takeovers of existing packages. Lesson: check new dependency names, limit install-time network access and watch for unexpected maintainer changes.

Lena applies the lesson immediately: any new dependency proposed for CampusEats is checked for names close to popular packages, its maintainers are reviewed, and its install scripts are noted before approval. These checks take a few minutes per new package and are recorded in the pull request.

20.3 Vulnerable dependencies

Decan et al. (2018) studied how vulnerabilities in npm packages propagate through dependency networks and how long fixes take to reach dependents. Lesson: monitor transitive dependencies and update promptly.

Transitive dependencies are those pulled in by the packages CampusEats chose, and they are most of the installed code. The society's SBOM makes them visible, and the nightly advisory check covers them as well as direct ones. When a fix exists only in a newer version of an intermediate package, the owner of the direct dependency is responsible for chasing the upgrade or recording an exception.

20.4 Build and distribution

Ladisa et al. (2023) describe attacks on build systems and distribution channels. Lesson: isolated builds, signed artifacts, hash checks and provenance.

For CampusEats, the build service is the most valuable target: anything it produces is deployed to every student. Lena checks who can change its configuration, confirms that changes need review and that each build records its inputs. Later in the course the society adds signatures and provenance, so the deployment step can verify that a bundle really came from that build service.

20.5 Trust in open source

Wermke et al. (2022) interviewed open-source maintainers about trust and security, finding varied practices and reliance on personal trust. Lesson: consumers should not assume upstream security processes.

Most packages CampusEats uses are maintained by volunteers in their spare time, much like the society itself. Lena treats this with respect rather than blame: the society reports problems politely, contributes fixes where it can and does not expect upstream projects to follow its own controls. Its protection comes from what it checks on its side, such as hashes and reviews.

20.6 CampusEats lessons

The society adopts a lookalike-name check, build network restrictions and weekly dependency updates.

Each change is small enough for volunteers to keep up. The lookalike check runs when a dependency is added, the build restrictions are a one-time configuration, and the weekly update is a short task rotated among members, with tests deciding whether an update is merged. Lena writes each lesson into the society's handbook with the case that motivated it, so new members understand the reason behind each rule.

Updating the cards

The case cards are reviewed each year as new research appears, so the lessons stay current. Lena adds a column for the standard that addresses each stage, such as SLSA for builds and the SSDF for response, linking cases to the frameworks from chapter 19.

Worked example

Lena prepares a one-page "case cards" handout: for each stage, one sentence on what went wrong in published cases and one on the matching CampusEats control. New members find it the clearest introduction to the topic.

Synthetic case. CampusEats applications are synthetic; the cited studies are real.

Errors and limits

Published cases are those that were discovered; undiscovered ones may differ.

Exercises

Synthesis

Published cases teach defensive lessons by stage without needing attack details.

Continue studying — chapter 20 of 40

← Chapter 19 (draft) · Course chapter index · Chapter 21 (draft) →

Worked answers

EX058. Lookalike names, code run during installation and takeovers of existing packages.

EX059. Monitor transitive dependencies and update promptly.

EX060. Consumers should not assume upstream projects have security processes.