Chapter 39 — Application and software supply chain security: maintainability
Lesson map
Lesson 39 published. Map, example, EX115.
flowchart TD
N0["Learning outcomes"]
N1["39.1 Abandoned components"]
N2["39.2 Replacement planning"]
N3["39.3 Reducing dependencies"]
N4["39.4 Ownership"]
N5["39.5 Supporting upstream"]
N6["39.6 Control maintenance"]
N7["Choosing new dependencies"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX115"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["39.1 Abandoned components"]
N2["39.2 Replacement planning"]
N3["39.3 Reducing dependencies"]
N4["39.4 Ownership"]
N5["39.5 Supporting upstream"]
N6["39.6 Control maintenance"]
N7["Choosing new dependencies"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX115"]
[Learning outcomes]
|
v
[39.1 Abandoned components]
|
v
[39.2 Replacement planning]
|
v
[39.3 Reducing dependencies]
|
v
[39.4 Ownership]
|
v
[39.5 Supporting upstream]
|
v
[39.6 Control maintenance]
|
v
[Choosing new dependencies]
|
v
[Worked example] --> [Exercise EX115]
Learning outcomes
You will (1) keep dependencies and controls maintainable over years; (2) plan replacement of abandoned components; (3) reduce dependency count; (4) document ownership.
39.1 Abandoned components
A component with no releases for two years and unanswered issues is a risk: flaws may never be fixed. Kwame finds four in ticket-web.
Signs of abandonment include no recent releases, open security reports without response and maintainers who no longer reply. Not every quiet project is abandoned: a small, finished library may need no changes. Kwame distinguishes them by checking whether reported bugs are answered. The four found were all used in ticket-web's request path, so a flaw in any of them would reach riders with no fix coming.
39.2 Replacement planning
For each, options are: replace with a maintained alternative, take over maintenance internally, or remove the feature. qr-make is replaced by a maintained library; one small helper is copied in and owned internally.
The choice depends on size and importance. Replacing qr-make is practical because maintained alternatives exist and the interface is small. Copying the small helper in makes sense because its few lines are easy to understand and test. Taking over maintenance of a large component would cost too much for a team Coastline's size, and removing a feature is chosen only when riders do not need it.
39.3 Reducing dependencies
Some packages are used for one tiny function. Removing them reduces attack surface and update work. Kwame removes 11 such packages.
A package used for one tiny function still brings its own dependencies, advisories and update work. Writing the function directly, in a few reviewed lines, removes all of that. Kwame chooses packages to remove by comparing how much of each is actually used. Each removal is a small pull request with tests, so mistakes are easy to spot and revert.
39.4 Ownership
Each dependency has an owning team listed in a file in the repository.
An owner receives advisories for the dependency, decides on upgrades and reviews proposals to remove it. Listing owners in the repository means the information changes through review and is visible to everyone. A check fails if a new dependency is added without an owner, so no package arrives unclaimed. When teams reorganise, the file is updated in the same change as the team structure. The owner is a team, not a person, so ownership survives holidays and staff turnover.
39.5 Supporting upstream
Coastline sponsors two critical upstream projects and contributes fixes, recognising findings from Wermke et al. (2022) that open-source maintainers often lack resources.
Sponsoring maintainers helps fund the time that fixes, reviews and releases require. Contributing fixes means Coastline's own patches are reviewed by people who know the code and reach every other user. Both reduce the chance that a critical project falls silent. Coastline chooses projects by how much of ticket-web depends on them, using the dependency graph to find the ones with the widest reach. It also reports flaws privately to these projects, following coordinated disclosure, so fixes arrive before details are public.
39.6 Control maintenance
Policies and checks are reviewed yearly; obsolete rules are removed.
A rule that no longer matches the system adds noise or, worse, gives false confidence. For example, a check for a package that has been removed still runs and passes, suggesting coverage that does not exist. The yearly review asks of each rule what risk it addresses, whether that risk still exists and whether the rule has fired. Rules with no remaining purpose are removed, and new ones are added for risks found during the year. The review results are recorded so auditors can see why rules changed.
Choosing new dependencies
Before adding a new dependency, developers check its maintenance activity, number of maintainers, security policy, licence and size. A short checklist in the pull-request template asks these questions. Small utilities are often better written in a few lines than imported, while complex functions such as cryptography should use well-maintained libraries rather than home-made code.
Licence checks
Licences of new components are checked automatically, and unusual licences go to legal for review before the component is merged.
Upgrade rhythm
A fixed weekly slot is reserved for dependency updates, so upgrades never pile up into risky large jumps.
Worked example
After a year, the component count falls from 220 to 196 and the median versions-behind drops from 1 minor to 0. Update pull requests merge faster because fewer conflicts occur.
Synthetic case. Counts are synthetic.
Errors and limits
Copying code in means owning its flaws; only copy small, well-understood code.
Exercises
- EX115 — Abandoned test. What marks a component as abandoned? Rubric: 3 = no releases 2 years; unanswered issues; 2 = partial; 1 = vague; 0 = none.
- EX116 — Options. List the three options for abandoned components. Rubric: 3 = replace, maintain internally, remove feature; 2 = two; 1 = one; 0 = none.
- EX117 — Year outcome. What changed after a year? Rubric: 3 = 220 to 196; versions-behind to 0; 2 = partial; 1 = vague; 0 = none.
Synthesis
Maintainable supply chains have fewer, owned, maintained components and supported upstreams.
Continue studying — chapter 39 of 50
← Chapter 38 (draft) · Course chapter index · Chapter 40 (draft) →