Chapter 41 — Application and software supply chain security: system optimization
Lesson map
Lesson 41 published. Map, example, EX121.
flowchart TD
N0["Learning outcomes"]
N1["41.1 Whole-system view"]
N2["41.2 Finding the bottleneck"]
N3["41.3 Changing the system"]
N4["41.4 Cost and risk"]
N5["41.5 Choosing next improvements"]
N6["41.6 Avoiding local optimisation"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX121"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["41.1 Whole-system view"]
N2["41.2 Finding the bottleneck"]
N3["41.3 Changing the system"]
N4["41.4 Cost and risk"]
N5["41.5 Choosing next improvements"]
N6["41.6 Avoiding local optimisation"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX121"]
[Learning outcomes]
|
v
[41.1 Whole-system view]
|
v
[41.2 Finding the bottleneck]
|
v
[41.3 Changing the system]
|
v
[41.4 Cost and risk]
|
v
[41.5 Choosing next improvements]
|
v
[41.6 Avoiding local optimisation]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX121]
Learning outcomes
You will (1) optimise the security system as a whole rather than individual controls; (2) find bottlenecks in remediation; (3) balance risk reduction against cost; (4) use data to choose the next improvement.
41.1 Whole-system view
Individual controls can each look good while the system performs poorly. Kwame maps the flow of an advisory from publication to deployed fix: detection (nightly check), triage (owner assigned), fix (code change), review, build, staging, production. He measures the median time in each step over six months of synthetic records.
The point is to find where time actually goes, which intuition often gets wrong. Each record carries a timestamp for every step, so the medians come straight from the data. Steps owned by different teams are shown on the same chart, which makes handovers visible as well as work.
41.2 Finding the bottleneck
Detection takes under a day, fix and review two days, but waiting for the next production release window takes a median of six days. The bottleneck is not security tooling; it is the release schedule.
Without the measurements, the team would likely have bought a faster scanner, since tools are easy to blame. The data shows that a fix sits ready for most of its waiting time. Once the cause is the schedule, the fix is a change to how releases are planned, not a purchase.
41.3 Changing the system
Coastline introduces a fast lane: security fixes that pass all checks can deploy any weekday morning with one approver. The median time from advisory to deployed fix falls from 10 to 4 days.
The fast lane changes a policy rather than adding a tool. All the usual checks still apply: tests, gate, signing, provenance and verification. Only the waiting for a release window is removed. The six days saved come straight from the bottleneck measured earlier. Morning deployment keeps the team at hand if something goes wrong.
41.4 Cost and risk
The fast lane adds some deployment risk, managed by automatic rollback and verification. Kwame compares expected exposure saved (6 days per advisory times about 20 relevant advisories a year) with the effort of extra deployments (about 30 minutes each).
Six days times twenty advisories is 120 days of exposure avoided each year, while twenty extra deployments at thirty minutes each cost about ten hours of engineering time. The comparison is rough, but the gap is large enough that the decision does not depend on precise numbers.
41.5 Choosing next improvements
With data on each step, the team ranks improvements by days saved per hour of effort. Faster triage through automatic owner assignment ranks next.
Ranking by days saved per hour of effort favours small changes with big effects, which are often overlooked in favour of large projects. Automatic owner assignment uses the dependency ownership file to route each advisory immediately, removing the day or so currently spent finding the right person. The ranking is repeated after each change, since removing one bottleneck reveals the next.
41.6 Avoiding local optimisation
Speeding up scanning further would save hours, not days; the system view keeps attention on what matters.
Each team naturally improves the part it controls, which can make the overall flow look busy without becoming faster. A scanner that finishes in ten minutes instead of twenty makes no difference when a fix waits six days for release. Coastline asks every proposed improvement to state which step of the measured flow it shortens and by how much. Proposals that cannot answer are deferred until the measurement shows they matter. This keeps effort where riders feel the difference.
Worked example
Kwame presents a simple chart of median days per step before and after the fast lane. Ingrid notes that the original 11-day tmpl exposure from year one would now be about 4 days, and adopts automatic owner assignment as the next project.
Synthetic case. Step times and counts are synthetic.
Errors and limits
Medians hide variation; a few slow items may need separate attention.
Exercises
- EX121 — Bottleneck. What was the bottleneck? Rubric: 3 = waiting for release window, median 6 days; 2 = partial; 1 = vague; 0 = none.
- EX122 — Fast lane effect. What effect did the fast lane have? Rubric: 3 = 10 to 4 days median; 2 = partial; 1 = vague; 0 = none.
- EX123 — Next improvement. What ranked next and why? Rubric: 3 = automatic owner assignment; days saved per effort; 2 = partial; 1 = vague; 0 = none.
Synthesis
Optimise the whole flow from advisory to deployment, guided by measured bottlenecks.
Continue studying — chapter 41 of 50
← Chapter 40 (draft) · Course chapter index · Chapter 42 (draft) →