Chapter 16 — Application and software supply chain security: methods II
Lesson map
Lesson 16 published. Map, example, EX046.
flowchart TD
N0["Learning outcomes"]
N1["16.1 Lock files"]
N2["16.2 Reviewing changes"]
N3["16.3 Adoption delay"]
N4["16.4 Choosing libraries"]
N5["16.5 Removing libraries"]
N6["16.6 Automated update requests"]
N7["Lock file in builds"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX046"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["16.1 Lock files"]
N2["16.2 Reviewing changes"]
N3["16.3 Adoption delay"]
N4["16.4 Choosing libraries"]
N5["16.5 Removing libraries"]
N6["16.6 Automated update requests"]
N7["Lock file in builds"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]
[Learning outcomes]
|
v
[16.1 Lock files]
|
v
[16.2 Reviewing changes]
|
v
[16.3 Adoption delay]
|
v
[16.4 Choosing libraries]
|
v
[16.5 Removing libraries]
|
v
[16.6 Automated update requests]
|
v
[Lock file in builds]
|
v
[Worked example] --> [Exercise EX046]
Learning outcomes
You will (1) pin dependency versions with hashes; (2) use lock files; (3) review dependency changes; (4) delay adoption of brand-new versions.
16.1 Lock files
A lock file records the exact version and hash of every direct and transitive library. Builds install exactly what the lock file says, so two builds of the same commit get the same libraries, and a changed file in the registry is detected because its hash no longer matches. For Brightwave, the lockfile is also the raw material for the nightly inventory: it records exactly which upload-kit version each project installed. A project without one was an unknown in the inventory until Aiko added it.
16.2 Reviewing changes
Changes to the lock file appear in pull requests. Reviewers look at which libraries changed, whether a new library was added, and whether a new maintainer or install script appeared. Large unexplained changes are questioned. A lockfile change of hundreds of lines for a one-library update deserves a question. Reviewers ask the author to explain what pulled in the extra libraries before approving the change. A new install script deserves particular attention, because it runs code during installation on the build machine. Diego's review of exactly such a change appears in the worked example below.
16.3 Adoption delay
Brightwave waits a few days before adopting brand-new library versions unless they fix a security advisory, since harmful versions are often discovered and removed quickly. Ohm et al. (2020) describe how malicious packages are spread. The delay applies to updates opened by the weekly bot, which waits until a new version has been public for a few days. A security fix skips the delay, because leaving a known flaw in place is the larger risk. The delay is a few days, short enough that ordinary updates are not held back for long.
16.4 Choosing libraries
Before adding a library, developers check maintenance activity, number of maintainers and how widely it is used. Zimmermann et al. (2019) showed how a few maintainer accounts can reach very large parts of an ecosystem, and Decan et al. (2018) compared dependency networks across ecosystems. Diego writes the answers into the pull request that adds the library, so the reasoning stays with the change. A library with one inactive maintainer and few users needs a stronger reason than one with several active maintainers. This matches Aiko's rule that a library should save real work and be actively maintained.
16.5 Removing libraries
Unused libraries are removed; each removal shrinks what must be tracked. Diego's first pass finds libraries that remained in manifests after features using them were removed. Each removal shortens the inventory, reduces advisory matches and makes later reviews faster. A removal still goes through review and tests, since an unused-looking library may be loaded indirectly. Fewer libraries also mean fewer weekly update pull requests to review. Diego asks owners to confirm that each library is unused before it is removed, and the build's tests confirm nothing broke. A removed library also stops appearing in future SBOMs, which keeps each client's component list shorter and easier to explain.
16.6 Automated update requests
A bot opens weekly update pull requests with tests run, so updates are small and regular rather than large and rare. Small weekly updates are also easier to review: a pull request changing one library is quick to check, while a yearly update changing dozens is hard to judge. Diego's later research compares projects with these weekly pull requests against projects still updated manually. The bot's pull requests run the full test suite and wait for a human review before merging. An update that fails tests stays open with its failure visible, which is how the date-library time-zone problem was caught before it reached any client.
Lock file in builds
The build fails if the lock file and the dependency list disagree, so nobody can forget to update it.
Worked example
Diego reviews an update pull request that adds a new transitive library with an install script. The team pauses, finds the parent library added it for an optional feature, and selects a configuration that avoids it.
Synthetic case. Libraries and changes are synthetic.
Errors and limits
Pinning stops surprise changes but also stops automatic fixes; pair it with regular updates.
Exercises
- EX046 — Lock file purpose. What does a lock file record? Rubric: 3 = exact versions and hashes of all libraries; 2 = partial; 1 = vague; 0 = none.
- EX047 — Adoption delay. Why delay brand-new versions? Rubric: 3 = harmful versions often found quickly; 2 = partial; 1 = vague; 0 = none.
- EX048 — Review finding. What did Diego's review find? Rubric: 3 = new transitive library with install script; avoided; 2 = partial; 1 = vague; 0 = none.
Synthesis
Pin, review and update regularly.
Continue studying — chapter 16 of 30
← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →