OpenCyber Academy
Bachelor's · Chapter 19 · English
Course code: OCA-106Chapter 19: OCA-106-C019

Chapter 19 — Application and software supply chain security: scope and theory

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 19 published. Map, example, EX055.

flowchart TD
  N0["Learning outcomes"]
  N1["19.1 Definitions"]
  N2["19.2 Why the chain matters"]
  N3["19.3 Trust theory"]
  N4["19.4 Frameworks"]
  N5["19.5 Taxonomy"]
  N6["19.6 CampusEats in theory"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX055"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["19.1 Definitions"]
  N2["19.2 Why the chain matters"]
  N3["19.3 Trust theory"]
  N4["19.4 Frameworks"]
  N5["19.5 Taxonomy"]
  N6["19.6 CampusEats in theory"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX055"]

[Learning outcomes]
    |
    v
[19.1 Definitions]
    |
    v
[19.2 Why the chain matters]
    |
    v
[19.3 Trust theory]
    |
    v
[19.4 Frameworks]
    |
    v
[19.5 Taxonomy]
    |
    v
[19.6 CampusEats in theory]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX055]

Learning outcomes

You will (1) define application security and software supply chain security; (2) explain why integrity of the whole chain matters; (3) describe frameworks that structure the field; (4) relate theory to CampusEats.

19.1 Definitions

Application security protects software from flaws in its design and code. Software supply chain security protects everything that goes into the software and how it reaches users: source code, dependencies, build systems, artifacts and distribution.

The two overlap: a flaw in a dependency is an application weakness that arrived through the supply chain, and a leaked deployment token is a supply-chain weakness that can expose the application. Lena uses both views when she looks at CampusEats, asking what the code does wrong and also how each piece of code and each artifact got to where it runs, and who could have changed it along the way.

19.2 Why the chain matters

CampusEats' code is a small fraction of what runs: most comes from open-source packages. Zimmermann et al. (2019) showed that in the npm ecosystem a few packages and maintainers can affect huge numbers of others, so a single compromise spreads widely.

Lena counts CampusEats' dependencies and finds that its own code is only a small part of what the build installs. A problem in one widely used package could reach the project through several routes at once, which is why the lockfile and the ownership list cover indirect dependencies as well as the ones the society chose directly.

19.3 Trust theory

Thompson's "Reflections on Trusting Trust" (1984) argued that you cannot fully trust code you did not create yourself, including compilers. Practical security therefore builds evidence, such as hashes, signatures and provenance, rather than assuming trust.

For CampusEats, evidence takes simple forms: the lockfile hash shows a package is the one recorded, a signature shows who published a release, and a build record shows which inputs produced a deployed bundle. Each piece of evidence narrows what the society has to take on trust, though it never removes trust completely, since someone must still decide whom to believe.

19.4 Frameworks

NIST SP 800-218 (SSDF) structures secure development practices; SLSA v1.0 defines build provenance levels; OWASP SAMM v2 measures programme maturity; OWASP ASVS defines application requirements.

Each answers a different question. The SSDF says which practices a team should follow; SLSA says how much can be trusted about how an artifact was built; SAMM measures how mature a programme is overall; ASVS lists what an application must do. Lena uses ASVS for CampusEats features and the SSDF for the society's development process, and notes where they overlap so that the same evidence serves both.

19.5 Taxonomy

Ladisa et al. (2023) organised attacks on open-source supply chains by stage and linked them to safeguards, giving a map of where controls belong.

Lena places CampusEats' own controls on that map: secret scanning at the source stage, isolated builds at the build stage and hash checks at the distribution stage. The map shows where the society has nothing, such as checks on who may publish releases of the packages it depends on, so the gaps become explicit decisions rather than unknowns.

19.6 CampusEats in theory

The leaked token was a source-stage problem; the hash mismatch was a distribution-stage check working as designed.

Placing both events on the taxonomy shows the society that its two early incidents sit at opposite ends of the chain. The leak needed controls on what developers commit; the mismatch showed a control at the end of the chain already working. Lena uses this to explain why the society cannot rely on a single tool and needs checks at several stages, each owned by someone.

19.7 Limits of theory

Frameworks describe what good looks like but not how much is enough for a small student project; judgement is needed.

Lena's approach is to pick a few controls that address the society's actual incidents and highest-rated threats, measure them, and add more only when evidence shows a gap. She records which framework practices are deliberately not followed and why, so that the choice can be revisited if the project grows, handles more money or takes on more developers. Grace reviews the list once a year.

Worked example

Lena maps CampusEats' controls onto the SSDF's four groups. Prepare: the society's code of conduct and training. Protect: repository access rules and secret scanning. Produce: reviews, tests, dependency checks. Respond: advisory monitoring and the incident notes. The weakest group is Prepare: there is no onboarding training on secure coding.

Synthetic case. Mappings are synthetic.

Errors and limits

A framework mapping shows practices exist, not that they are effective.

Exercises

Synthesis

Supply chain security extends application security to everything that builds and delivers the software.

Continue studying — chapter 19 of 40

← Chapter 18 (draft) · Course chapter index · Chapter 20 (draft) →

Worked answers

EX055. Application security addresses design and code flaws; supply chain security covers everything that goes into the software and how it reaches users.

EX056. That you cannot fully trust code you did not create yourself, even compilers.

EX057. Prepare, because there was no onboarding training on secure coding.