Chapter 17 — Control and feedback basics
Lesson map
Lesson 17 published. Map, example, EX049.
flowchart TD
N0["Learning outcomes"]
N1["17.1 Feedback loops"]
N2["17.2 The advisory loop"]
N3["17.3 Delays"]
N4["17.4 Oscillation"]
N5["17.5 Positive feedback"]
N6["17.6 Measuring the loop"]
N7["Setting targets"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX049"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["17.1 Feedback loops"]
N2["17.2 The advisory loop"]
N3["17.3 Delays"]
N4["17.4 Oscillation"]
N5["17.5 Positive feedback"]
N6["17.6 Measuring the loop"]
N7["Setting targets"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX049"]
[Learning outcomes]
|
v
[17.1 Feedback loops]
|
v
[17.2 The advisory loop]
|
v
[17.3 Delays]
|
v
[17.4 Oscillation]
|
v
[17.5 Positive feedback]
|
v
[17.6 Measuring the loop]
|
v
[Setting targets]
|
v
[Worked example] --> [Exercise EX049]
Learning outcomes
You will (1) explain feedback loops in engineering; (2) apply feedback to security processes; (3) recognise delays and oscillation; (4) design stable improvement loops.
17.1 Feedback loops
A controller measures an output, compares it with a target and adjusts. A thermostat measures temperature and switches heating. Security processes are loops too: measure open advisories, compare with targets, adjust effort.
Every loop has four parts: a sensor that measures, a target, a comparison and an actuator that changes something. If any part is missing, the loop does not work. A dashboard nobody reads has a sensor without comparison; a target nobody acts on has comparison without an actuator. Kwame checks each security process for all four parts.
17.2 The advisory loop
Coastline's target: no critical advisory open more than 7 days. Each morning, the advisory check reports open items; the team adjusts priorities. The loop's sensor is the SBOM-based check (chapter 24); its actuator is engineering time.
The target is simple enough that everyone knows whether it is being met. The daily report is the comparison, and the morning stand-up is where effort is adjusted. If the SBOM is wrong, the sensor misreads, and the loop steers confidently in the wrong direction, so SBOM accuracy is checked as part of the loop.
17.3 Delays
Feedback with long delays causes trouble. If the advisory report were monthly, problems would be found late and fixes would come in bursts. Daily reports shorten the loop.
Delay hides problems and also makes responses overshoot. With a monthly report, a team sees many advisories at once and rushes to fix them all, then has little to do until the next report. Daily reports spread the work evenly. The delay that matters is the whole path from advisory publication to the team noticing, not just how often the report runs.
17.4 Oscillation
Overreacting causes swings: one week everyone drops features to fix low-severity items, the next week nothing gets fixed. Clear thresholds and steady capacity keep the loop stable.
Swings waste effort and erode trust in the process. A threshold such as 'criticals first, highs within 30 days' tells everyone what deserves immediate attention, and reserved capacity, for example one engineer-day per week, means the work does not depend on the mood of the week. Kwame compares weekly fix counts to see whether swings shrink.
17.5 Positive feedback
Some loops amplify: more noise leads to ignoring alerts, which leads to more unresolved items and more noise. Recognising such loops helps break them early.
The cure is to break the loop at its weakest point. Removing duplicate and irrelevant alerts lowers noise, which makes people more willing to read the rest, which leads to more items being resolved. Good loops can amplify too: quick fixes build confidence, which encourages people to report problems early. Spotting which direction a loop is turning is the first step to steering it.
17.6 Measuring the loop
The loop's performance is measured by time to remediate, studied in chapter 29.
Remediation time shows whether the loop as a whole works, combining detection, decision and fix. It is measured from when an advisory applies to Coastline until the fix is deployed, not merely merged, since riders are only protected once production changes. Coastline tracks the median and the slowest cases separately, because an average can look healthy while a few critical advisories wait for weeks. Breaking the time into stages, such as noticing, deciding and deploying, shows which part of the loop to improve next.
Setting targets
Targets come from risk: 7 days for critical, 30 for high and 90 for medium advisories. They are reviewed yearly. Targets that are never met are not useful signals, and targets that are always easily met may be too loose; Kwame plots the share met each month to see whether the targets still drive the right behaviour.
Worked example
After Coastline reduces noise by removing duplicate advisories (the same flaw reported by two sources), the daily list shrinks from 40 to 12 items and the team clears criticals within the target for three months running.
Synthetic case. Targets and counts are synthetic.
Errors and limits
Process loops involve people, who are less predictable than machines; use loops as a guide.
Exercises
- EX049 — Loop parts. Name the sensor and actuator of the advisory loop. Rubric: 3 = SBOM-based check; engineering time; 2 = one; 1 = vague; 0 = none.
- EX050 — Delay effect. What happens with long feedback delays? Rubric: 3 = late discovery, fixes in bursts; 2 = partial; 1 = vague; 0 = none.
- EX051 — Noise fix. What reduced the daily list from 40 to 12? Rubric: 3 = removing duplicate advisories; 2 = partial; 1 = vague; 0 = none.
Synthesis
Short, stable feedback loops keep security work under control.
Continue studying — chapter 17 of 50
← Chapter 16 (draft) · Course chapter index · Chapter 18 (draft) →