Chapter 14 — Software engineering
Lesson map
Lesson 14 published. Map, example, EX040.
flowchart TD
N0["Learning outcomes"]
N1["14.1 Tools are products"]
N2["14.2 Gate widening"]
N3["14.3 CI fixtures"]
N4["14.3b Release trains vs hotfixes"]
N5["14.1b Branching model"]
N6["Practice note"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX040"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["14.1 Tools are products"]
N2["14.2 Gate widening"]
N3["14.3 CI fixtures"]
N4["14.3b Release trains vs hotfixes"]
N5["14.1b Branching model"]
N6["Practice note"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX040"]
[Learning outcomes]
|
v
[14.1 Tools are products]
|
v
[14.2 Gate widening]
|
v
[14.3 CI fixtures]
|
v
[14.3b Release trains vs hotfixes]
|
v
[14.1b Branching model]
|
v
[Practice note]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX040]
Learning outcomes
You will (1) put assessment tools under version control with review; (2) gate scope-widening changes; (3) keep CI on synthetic fixtures only.
14.1 Tools are products
TrackScope and FindingsDesk are software. They need repositories, code review, tagged releases and changelogs. A ROE that cites "TrackScope" without a version is incomplete; cite TrackScope v0.9.2 or the git SHA used.
Without a version, two engineers can run different builds and disagree about what the tool denied. Tags and changelogs make that disagreement checkable. Code review catches a scope check that fails open before it reaches an engagement. Sam pastes the SHA into the kickoff notes and refuses to start if the running binary differs.
14.2 Gate widening
Merges that add a CIDR, open a port or remove a deny-list entry require a second reviewer and a linked authorization ticket. Merges that only tighten scope can be lighter. Encode this in CODEOWNERS or a required check that diffs the scope files.
Widening scope is an authorization event, so it needs the same dual attention as a ROE change. Tightening can move faster because it cannot create new targets. A required check on scope diffs stops a quiet CIDR addition in a large pull request. Sam links every widening merge to the client's written approval ticket.
14.3 CI fixtures
Continuous integration runs the labs and unit tests on synthetic data. Never point CI at a client network. Seed data lives in the repo; secrets for real engagements live in a vault and never in CI logs.
Synthetic case — Riverstone Transit. A PR added 10.30.0.0/16 to scope "for next month". CI's scope-diff check blocked merge until ticket AUTH-442 was linked and a second owner approved.
CI that can reach a client network would turn every broken test into a possible probe. Synthetic fixtures keep failures local and repeatable. Secrets in logs become incidents; vaults keep them out of build output. Sam's pipelines have no routes to engagement networks and fail if someone adds one.
14.4 Errors and limits
Version tags can drift from what operators actually run; record the running version in the engagement log at start.
Operators install hotfixes by hand and forget to update the tag on the checklist. Logging the running version at start makes the mismatch visible before traffic flows. Sam compares that log line to the ROE pin and stops the window on disagreement until operators install the pinned build or the ROE is revised. A sticky note on a laptop is not a version pin.
14.3b Release trains vs hotfixes
Normal improvements ride a release train with Lab I/II. Safety hotfixes may skip features but not verification: a minimal fail-closed regression pack is mandatory. Tag hotfixes clearly so an engagement can pin either the train build or the hotfix SHA with eyes open.
Safety fixes must still prove fail-closed behaviour, even when features wait. Pinning with eyes open means the client knows which binary produced the evidence. Sam keeps the regression pack small so hotfixes stay fast without skipping it.
14.1b Branching model
Use short-lived branches with mandatory CI on synthetic fixtures. Long-lived feature branches diverge from safety fixes on main and recreate fail-open merges. Protect main with required reviewers and status checks named after Lab I safety rows.
Short branches pick up safety fixes from main instead of reinventing them weeks later. Required checks named after Lab I rows make the safety suite impossible to skip with a casual approve. Sam deletes stale branches weekly so divergence cannot hide. A branch that falls more than a week behind main must be rebased and pass the Lab I checks again before review.
Practice note
Version pins appear in the engagement kickoff checklist beside the ROE hash. Operators read the pin aloud before the window opens so nobody silently runs a laptop build. If the pin and the running binary disagree, the window does not start until someone files an AUTH note or rolls back. That ritual has prevented more incidents than any banner in the UI, because it forces a human to look at the SHA while the client is still on the call.
Exercises
- EX040 — Version line. Write the method sentence that pins TrackScope for an engagement. Rubric: 3 = name, version/SHA, date loaded; 2 = name+version; 1 = name only; 0 = none.
- EX041 — Gate rule. Write a one-sentence merge policy for scope files. Rubric: 3 = second reviewer + auth ticket for widen; 2 = reviewer only; 1 = vague; 0 = none.
- EX042 — CI boundary. Why must CI never use client VPN credentials? Rubric: 3 = unauthorized automation risk, secret leakage in logs, non-determinism; 2 = one solid reason; 1 = vague; 0 = wrong.
Synthesis
Treat assessment software like production software: versions, review gates and synthetic CI.
Continue studying — chapter 14 of 50
← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →