Chapter 24 — Application and software supply chain security: controls
Lesson map
Lesson 24 published. Map, example, EX070.
flowchart TD
N0["Learning outcomes"]
N1["24.1 Preventive controls"]
N2["24.2 Detective controls"]
N3["24.3 Corrective controls"]
N4["24.4 Policy in CI"]
N5["24.5 Exceptions"]
N6["24.6 Effectiveness"]
N7["24.7 Proportion"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX070"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["24.1 Preventive controls"]
N2["24.2 Detective controls"]
N3["24.3 Corrective controls"]
N4["24.4 Policy in CI"]
N5["24.5 Exceptions"]
N6["24.6 Effectiveness"]
N7["24.7 Proportion"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX070"]
[Learning outcomes]
|
v
[24.1 Preventive controls]
|
v
[24.2 Detective controls]
|
v
[24.3 Corrective controls]
|
v
[24.4 Policy in CI]
|
v
[24.5 Exceptions]
|
v
[24.6 Effectiveness]
|
v
[24.7 Proportion]
|
v
[Worked example] --> [Exercise EX070]
Learning outcomes
You will (1) select preventive, detective and corrective controls for the supply chain; (2) implement policy checks in CI; (3) manage exceptions; (4) review control effectiveness.
24.1 Preventive controls
Branch protection with required review; secrets kept out of code; lockfile hashes; lookalike-name checks for new dependencies; isolated builds with limited network.
Preventive controls stop a problem before it happens and are the cheapest when they work. Lena lists each one with what it prevents, who maintains it and how it is tested, and checks that branch protection cannot be turned off by ordinary members. She also checks that every preventive control fails safe: if the lookalike check cannot reach its data, the new dependency waits rather than being approved.
24.2 Detective controls
Secret scanning after push; nightly advisory checks against SBOMs; alerts on failed integrity checks; logs of deployments.
Detective controls assume prevention will sometimes fail. Each alert goes to a named person, and the nightly advisory check posts a summary to the society's channel only when something new appears, so routine runs do not train members to ignore it. Lena checks each detective control by triggering it with a harmless test, such as a synthetic secret, to confirm alerts arrive. Each alert is acknowledged.
24.3 Corrective controls
Secret rotation procedure; dependency update process; rollback to the previous release.
Each corrective control has a written procedure in the runbook and has been tried at least once. The rollback was tested by redeploying the previous release in the test environment, which took a few minutes. Practising before an incident means members know the steps and can act quickly, and it often reveals missing permissions or steps that would otherwise be found at the worst time. Results are written down after each practice.
24.4 Policy in CI
A CI step fails the build when: a high-severity advisory affects a dependency without an approved exception, a new dependency has no owner, or the lockfile is out of date. NIST SP 800-218 practices PW.4 (reuse well-secured software) and RV.1 (identify vulnerabilities continuously) support these checks.
Lena adds a clear message to each failure, so developers know what to fix. For example, a failure for a missing owner names the new package and links to the ownership list. Clear messages make the policy feel like help rather than an obstacle, and members fix most failures without asking anyone. Lena also tracks how often each rule fails the build.
24.5 Exceptions
An exception records the reason, owner and expiry date; expired exceptions fail the build again.
Exceptions are visible in the repository and reviewed when they expire. For example, an advisory affecting a feature CampusEats does not use may get an exception with a short expiry while the owner waits for a fixed release. Because expired exceptions fail the build, they cannot be forgotten. Lena keeps the number of open exceptions in the termly summary as a sign of debt. Each is listed with its owner.
24.6 Effectiveness
Each control has a measure: number of times it caught something, false alarms and time cost.
Lena collects these from logs each term. A control that never catches anything is not necessarily useless, since it may deter mistakes, but one that raises many false alarms or slows every build needs attention. The figures help the society decide where to improve, and they show the security office that controls are being checked rather than merely installed. Time cost is measured per build and per review, so the society can see the burden members carry.
24.7 Proportion
CampusEats is a volunteer project; controls must be light enough that members keep using them.
Lena keeps each check fast, explains its purpose in the handbook and removes checks that cost more than they protect. A control members work around is worse than none, because it gives false confidence. When a new control is proposed, the society tries it for a month and reviews the time it costs and what it caught before making it permanent. Grace supports this trial approach for other student projects.
Review cycle
Controls are reviewed each term: are they still catching problems, are false alarms rising, and do members understand them? A control that has caught nothing for a year is checked with a synthetic test to make sure it still works, rather than removed.
Ownership
Each control has a named owner in the society.
Worked example
In one term, the CI policy blocks four builds: two for a new high advisory (fixed within a day), one for a dependency without an owner (owner added) and one for an outdated lockfile. Members report the checks are clear and quick.
Synthetic case. Controls and counts are synthetic.
Errors and limits
Controls in CI protect what goes through CI; manual changes outside it are not covered, so block them.
Exercises
- EX070 — Control types. Give one preventive, one detective and one corrective control. Rubric: 3 = e.g. lockfile hash; advisory check; rollback; 2 = two; 1 = one; 0 = none.
- EX071 — CI policy. List the three CI policy failures. Rubric: 3 = high advisory without exception; no owner; outdated lockfile; 2 = two; 1 = one; 0 = none.
- EX072 — Term results. What did the policy block in one term? Rubric: 3 = 2 advisory, 1 no owner, 1 outdated lockfile; 2 = partial; 1 = vague; 0 = none.
Synthesis
Combine preventive, detective and corrective controls, enforced in CI and kept proportionate.
Continue studying — chapter 24 of 40
← Chapter 23 (draft) · Course chapter index · Chapter 25 (draft) →