<a id="ch-01"></a>

## Chapter 1 — Application and software supply chain security: foundations and decisions

### Learning outcomes

You will (1) explain what application and software supply chain security means for a small organisation's website; (2) recognise the main risks; (3) make simple, proportionate decisions; (4) set priorities for a month of work.

### 1.1 The opening case

Owen Clarke is the only IT person at the fictional charity Riverside Food Network. He is taking a one-month rapid course at the fictional Kestrel Skills Centre with tutor Nadia Haddad. The charity's donation website runs on a common website platform with a handful of plugins. A volunteer installed most of them years ago. Last month a donor reported that the donation page briefly showed an error mentioning an outdated form component, and Owen realised nobody knew which components the site used or who kept them updated.

### 1.2 What the subject covers

Application security protects the website's own code and settings. Software supply chain security protects everything the site is built from: the platform, its plugins, themes and the services they call, and the path by which each arrives and is updated. For a small charity, the supply chain is most of the website.

Owen's site shows the split. The charity wrote almost nothing itself: its settings and a few page templates are its own code. The donation form, the event calendar, the photo gallery, the newsletter plugin, the theme and the platform all came from other people, and the error message a donor saw last month came from one of them.

### 1.3 Main risks

Outdated components with known flaws (OWASP Top 10:2021 A06); components that are no longer maintained; components from unofficial sources; weak administrator sign-in (A07); and integrity failures, where an update or file is changed before it arrives (A08).

Each risk has a face on Owen's site. The donation form was out of date and had a published advisory (A06). The event calendar had not been released for over four years. A component downloaded from an unofficial page could be anything. Three administrator accounts had no multi-factor sign-in (A07). And an update file changed on its way to him is what the hash check guards against (A08).

### 1.4 Proportionate decisions

Owen has a few hours a week. He decides by asking three questions for each risk: how likely is it, how much harm would it cause to donors and the charity, and how cheap is the fix? Cheap fixes for likely, harmful risks go first.

Turning on multi-factor sign-in for the three administrator accounts is the clearest example: an attack on a password is likely, an administrator account could change everything on the site, and the fix costs minutes. Replacing the event calendar is harmful to leave but takes longer, so it comes later in the month.

### 1.5 Frameworks as guides

NIST SP 800-218 (SSDF) and OWASP SAMM v2 are written for software producers and larger organisations, but their ideas scale down: know your components, keep them updated, check what you install, and have a plan for problems.

Owen's month uses each idea at his scale. "Know your components" is the plugin list he exports in week 3. "Keep them updated" is the donate-form update and the weekly routine. "Check what you install" is the hash comparison in the release checklist. "Have a plan" is his rule to stop and call the host and Nadia if he finds signs of misuse.

### 1.6 The month's plan

Week 1 foundations and decisions; week 2 scope and safe practice; week 3 components, data and dependencies; week 4 guided lab and putting it together.

The order matters. Owen cannot decide what to update until he knows what the site uses, and he should not change anything until he has permission, a backup and a staging copy. So the inventory comes in week 3, after the scope, and the donate-form update in week 4, after both. The first week's quick win, multi-factor sign-in, needs no inventory and starts at once.

### Worked example

Owen lists his first decisions: turn on multi-factor sign-in for the three administrator accounts (cheap, high value), list every plugin and its version (cheap, needed for everything else), and ask the platform host whether automatic security updates are available. Nadia agrees these are the right first steps.

> **Synthetic case.** Riverside Food Network and all people and events are synthetic.

### Errors and limits

Proportionate does not mean minimal; some risks need more effort than they first seem to.

### Exercises

- **EX001 — Opening problem.** What did Owen realise after the donor's report? *Rubric:* 3 = nobody knew components or owners; 2 = partial; 1 = vague; 0 = none.
- **EX002 — Supply chain scope.** What does the charity's software supply chain include? *Rubric:* 3 = platform, plugins, themes, services, update path; 2 = three; 1 = one; 0 = none.
- **EX003 — Top 10 links.** Which Top 10:2021 categories match the main risks? *Rubric:* 3 = A06, A07, A08; 2 = two; 1 = one; 0 = none.
- **EX004 — Deciding questions.** What three questions guide Owen's decisions? *Rubric:* 3 = likelihood, harm, cost of fix; 2 = two; 1 = one; 0 = none.
- **EX005 — First decisions.** Name Owen's first three decisions. *Rubric:* 3 = MFA, component list, ask about auto-updates; 2 = two; 1 = one; 0 = none.
- **EX006 — Framework scaling.** How do SSDF and SAMM ideas scale down? *Rubric:* 3 = know, update, check, plan; 2 = three; 1 = one; 0 = none.
- **EX007 — Week three.** What does week 3 cover? *Rubric:* 3 = components, data and dependencies; 2 = partial; 1 = vague; 0 = none.
- **EX008 — Most of the site.** Why is the supply chain "most of the website" here? *Rubric:* 3 = built from others' components; 2 = partial; 1 = vague; 0 = none.
- **EX009 — Unmaintained risk.** Why is an unmaintained component a risk? *Rubric:* 3 = future flaws never fixed; 2 = partial; 1 = vague; 0 = none.
- **EX010 — Integrity failure.** Give an example of an integrity failure. *Rubric:* 3 = update changed before arrival; 2 = partial; 1 = vague; 0 = none.
- **EX011 — MFA value.** Why is multi-factor sign-in a good first step? *Rubric:* 3 = cheap and high value; 2 = partial; 1 = vague; 0 = none.
- **EX012 — Proportionate limit.** What warning comes with proportionate decisions? *Rubric:* 3 = some risks need more effort; 2 = partial; 1 = vague; 0 = none.
- **EX013 — Nadia's role.** What did Nadia do with Owen's list? *Rubric:* 3 = agreed they were right first steps; 2 = partial; 1 = vague; 0 = none.

### Synthesis

Know the components, fix cheap high-value risks first and plan the month.

### Continue studying — lesson 01 (chapter 01 of 20)

[← Course home](../../README.md) · [Course chapter index](../SUBJECTS.md) · [Chapter 02 →](#ch-02)

## Worked answers

<a id="answer-ex001"></a>
**EX001.** Nobody knew which components the site used or who updated them.

<a id="answer-ex002"></a>
**EX002.** The platform, plugins, themes, services and how each arrives and updates.

<a id="answer-ex003"></a>
**EX003.** A06 outdated components, A07 authentication failures, A08 integrity failures.

<a id="answer-ex004"></a>
**EX004.** How likely, how much harm, and how cheap the fix is.

<a id="answer-ex005"></a>
**EX005.** Enable multi-factor sign-in, list plugins and versions, ask about automatic updates.

<a id="answer-ex006"></a>
**EX006.** Know components, keep them updated, check what is installed, plan for problems.

<a id="answer-ex007"></a>
**EX007.** Components, data and dependencies.

<a id="answer-ex008"></a>
**EX008.** The site is built almost entirely from other people's components.

<a id="answer-ex009"></a>
**EX009.** Future flaws will never be fixed.

<a id="answer-ex010"></a>
**EX010.** An update or file changed before it arrives.

<a id="answer-ex011"></a>
**EX011.** It is cheap and protects administrator accounts strongly.

<a id="answer-ex012"></a>
**EX012.** Some risks need more effort than they first seem to.

<a id="answer-ex013"></a>
**EX013.** She agreed they were the right first steps.
