Chapter 9 — Application and software supply chain security: tools and methods
Lesson map
Lesson 09 published. Map, example, EX033.
flowchart TD
N0["Learning outcomes"]
N1["9.1 The inventory"]
N2["9.2 Advisories"]
N3["9.3 Comparing"]
N4["9.4 Prioritising"]
N5["9.5 Simple tools"]
N6["9.6 Keeping current"]
N7["Checking the inventory"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX033"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["9.1 The inventory"]
N2["9.2 Advisories"]
N3["9.3 Comparing"]
N4["9.4 Prioritising"]
N5["9.5 Simple tools"]
N6["9.6 Keeping current"]
N7["Checking the inventory"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX033"]
[Learning outcomes]
|
v
[9.1 The inventory]
|
v
[9.2 Advisories]
|
v
[9.3 Comparing]
|
v
[9.4 Prioritising]
|
v
[9.5 Simple tools]
|
v
[9.6 Keeping current]
|
v
[Checking the inventory]
|
v
[Worked example] --> [Exercise EX033]
Learning outcomes
You will (1) build and use a plugin inventory; (2) compare versions with advisories; (3) choose simple, reliable tools; (4) keep results current.
9.1 The inventory
A nightly script lists, for every customer site, each installed plugin and version from the application's own records. The output is a CSV kept by Pinecrest and visible to support. Using the application's own records makes the list quick and consistent across hundreds of sites. The CSV gives support a single place to answer 'which sites run resize-plugin 2.4.1?', a question nobody could answer during the Ferncroft case. The monthly spot check against plugin folders catches anything the records miss. The CSV is read-only to support, so nobody edits inventory rows by hand.
9.2 Advisories
Vendors and security databases publish advisories naming the affected component, the fixed version and severity. Pinecrest subscribes to advisory feeds for the shop application and its popular plugins. An advisory gives exactly what the comparison script needs: the component name, the version that fixes the flaw and the severity. Subscribing to feeds for the shop application and popular plugins covers most of Pinecrest's installations, since seven plugins account for over 80% of them. Each feed's entries are checked against the advisory text before a ticket is raised.
9.3 Comparing
A script compares installed versions with the fixed version: anything lower is affected. Version strings must be compared as numbers, not text, or 2.10 would sort before 2.9. The lab in Chapter 12 does this with number tuples, so 2.4.1 is correctly lower than 2.4.3 and 4.9.9 lower than 5.1.0. Labels such as 2.4.1-beta would break a simple conversion, which is why Tomás adds a test for them when he checks the inventory. An incorrect comparison could miss affected sites or flag fixed ones, so the script is tested with known pairs.
9.4 Prioritising
High severity on public pages comes first. EPSS scores (Jacobs et al., 2021) can help judge how likely exploitation is when many advisories arrive at once, alongside CWE categories such as those in MITRE's CWE Top 25 to understand the kind of weakness. Severity alone can mislead when dozens of advisories arrive at once, so these signals help order the work. Pinecrest uses EPSS only as one input, and Tomás records which advisories were moved up or down because of it, so the order can be reviewed.
9.5 Simple tools
Stdlib scripts with clear output are easy to review and run anywhere. A short standard-library script can be read by a supervisor in minutes and run on any support machine without installing anything. The four labs in this course follow that pattern, and the nightly job grows from scripts written the same way, so reviewers can check exactly what each step does before trusting its results. Clear output, one line per finding, makes the results easy to paste into tickets.
9.6 Keeping current
The inventory runs nightly, so it reflects updates made the day before. A nightly run means an advisory published today can be compared with yesterday's installed versions by tomorrow morning. Updates applied during the day appear in the next run, so a fixed site drops out of the findings without anyone editing a list by hand. Stale inventory data would send technicians to sites that had already been updated the day before. If a nightly run fails, the coverage alert from Chapter 14 makes the gap visible.
Checking the inventory
Once a month Tomás picks five sites and compares the inventory with a direct listing of plugin folders. The first check finds one site with a plugin folder copied by hand that the application did not list; it is added to the inventory process. He also checks that version strings with extra labels, such as 2.4.1-beta, are handled correctly by the comparison script and adds a test for them.
Worked example
The first inventory shows 412 customer sites with 1,960 plugin installations and 38 distinct plugins. Seven plugins account for over 80% of installations, so advisories for those seven are watched most closely.
Synthetic case. Counts are synthetic.
Errors and limits
An inventory from the application's own records may miss files added by hand; compare with file listings occasionally.
Exercises
- EX033 — Inventory content. What does the inventory list? Rubric: 3 = site, plugin, version; 2 = two; 1 = one; 0 = none.
- EX034 — Version compare. Why compare versions as numbers? Rubric: 3 = text puts 2.10 before 2.9; 2 = partial; 1 = vague; 0 = none.
- EX035 — Priority. What comes first? Rubric: 3 = high severity on public pages; 2 = partial; 1 = vague; 0 = none.
- EX036 — Seven plugins. Why watch seven plugins closely? Rubric: 3 = over 80% of installations; 2 = partial; 1 = vague; 0 = none.
Synthesis
Inventory and advisory comparison find what needs updating.
Continue studying — chapter 09 of 18
← Chapter 08 (draft) · Course chapter index · Chapter 10 (draft) →