Chapter 3 — Programming I
Lesson map
Lesson 03 published. Map, example, EX007.
flowchart TD
N0["Learning outcomes"]
N1["3.1 Purpose"]
N2["3.2 Unsafe patterns"]
N3["3.3 Synthetic first"]
N4["3.4 Review"]
N5["3.5 Determinism"]
N6["3.6 Course labs"]
N7["3.7 Applied note"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX007"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["3.1 Purpose"]
N2["3.2 Unsafe patterns"]
N3["3.3 Synthetic first"]
N4["3.4 Review"]
N5["3.5 Determinism"]
N6["3.6 Course labs"]
N7["3.7 Applied note"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX007"]
[Learning outcomes]
|
v
[3.1 Purpose]
|
v
[3.2 Unsafe patterns]
|
v
[3.3 Synthetic first]
|
v
[3.4 Review]
|
v
[3.5 Determinism]
|
v
[3.6 Course labs]
|
v
[3.7 Applied note]
|
v
[Worked example] --> [Exercise EX007]
Learning outcomes
You will (1) write small Python tools for offline evidence; (2) refuse unsafe patterns; (3) test tools on synthetic data.
3.1 Purpose
Sam automates scope membership checks, hash verification and finding ranking — never exploitation. Each automated check replaces a manual step that people skip when tired: is this address in the signed /26, does this evidence file still match its recorded hash, which open findings rank highest by severity and asset? None of these scripts sends traffic to a target. Keeping automation on the safe side of that line means a bug in Sam's code can mislabel a report, but cannot reach the ledger or SWIFT.
3.2 Unsafe patterns
No hard-coded secrets, no disabled TLS verification, no unsanitised shell-outs to scanners, no retries without caps. Each rule maps to a real failure: a hard-coded key ends up in a repository, disabled TLS verification hides an interception, a hostname passed to a shell can carry extra commands, and an uncapped retry loop can turn a polite check into a flood against a fragile host. Sam's review checklist lists these four by name so reviewers look for them first, and CI rejects the two that can be detected automatically before any human reads the code.
3.3 Synthetic first
Every tool runs on documentation-range addresses and fake files before any engagement window. Documentation ranges such as 198.51.100.0/24 cannot route to real hosts, so a mistake during development reaches nothing. Sam runs every new tool against the synthetic TRB scope first, including the SWIFT exclusion at .20, and keeps the outputs as the expected results. Only when those outputs match the hand-worked answers does the tool become eligible for an engagement window, and the approval cites the synthetic run by date. An approval request without a dated synthetic run attached is refused, however urgent the window.
3.4 Review
A second engineer reads Sam's scripts for scope path mistakes. The reviewer's first job is to trace every path by which an address enters the script and confirm it passes through the TrackScope membership check before use. Common mistakes include a debug flag that skips the check, a second input file read without filtering, and an exclusion list loaded after the targets. The reviewer signs the review in FindingsDesk, so the record shows who checked which version and when. Unsigned scripts cannot run in a window.
3.5 Determinism
Seed randomness and pin interpreter versions so PulseMap demos are reproducible. A PulseMap demo that shows different coverage numbers on two runs cannot be trusted by anyone watching. With a fixed seed and a pinned Python version, the same synthetic input always produces the same tiles, and a changed number means changed data or code, not chance. Sam records the seed and version in each demo's notes so a reviewer can reproduce the exact screen later and compare it with the saved output.
3.6 Course labs
Labs in this book follow these rules and embed real outputs. Each lab in this book runs offline on the Python 3 standard library, uses documentation-range addresses and synthetic files, and prints output that was captured from a real run. If your output differs from the printed one, the difference is information: a changed input, a different interpreter or a bug. Treat it the way Sam treats a PulseMap regression, by finding the cause before trusting either result. None of the labs needs network access, so they can be run on a laptop with networking switched off.
3.7 Applied note
Dry-run output is pasted into the engagement channel before any write mode runs. Peers have two minutes to object. Sam once caught a path traversal into an evidence archive because a teammate read the dry-run carefully. Social review beats solitary cleverness for operational scripts. Two minutes is short enough not to delay a window and long enough for a careful reader. The pasted output lists every target address, the method card and the write paths the script will touch, so a reader can compare each line with the signed /26 and the SWIFT exclusion. Any reader's objection pauses the run until it is resolved and noted in the window log.
3.8 Test data policy
Synthetic customers in fixtures use obviously fake national IDs. Sam rejects fixtures that reuse real-looking personal numbers even when unused in production. Habit transfer matters. A fixture that resembles a real identity number can be copied into a test against production by someone in a hurry. Obviously fake values cannot be mistaken for customer data, and the habit carries into every later engagement. A reviewer who sees a plausible identity number in a fixture asks where it came from; a value like FAKE-000-001 ends the question immediately and cannot be confused with a customer during an incident.
3.9 Secret scanning in CI
Platform repos fail CI if high-entropy strings look like keys. Sam whitelists only test fixtures clearly marked FAKE. A real-looking key in a test file still trains people to ignore the warning, so marking is mandatory. Each whitelisted fixture is listed with its owner and the reason it is safe, and the list is reviewed whenever CI rules change. Whitelisting by marker rather than by file path means a real key pasted into a fixtures folder is still caught. When CI blocks a commit, the developer rotates the string even if it was only ever local.
3.10 Rejected-snippet board
Sam's script review board hangs three rejected snippets: a requests call with verify=False, a subprocess with shell=True on a hostname, and a retry loop without jitter. New interns initial the board after reading it. The board is silly and effective. When Sam almost pastes verify=False "just in staging", he sees his own initials and stops. Each snippet sits beside the safe version: verify left on with TRB's internal CA, a subprocess called with an argument list, and a retry loop with a cap and backoff.
The board gets a fourth example whenever CI catches a new anti-pattern. Sam dates each snippet. Each new snippet carries a one-line note on what CI caught and why it was dangerous, such as an uncapped retry against a slow host. Interns are asked to explain one snippet in their own words during their first week. The note names the rule, not the person who wrote the code. Sam's team reviews the board yearly and retires snippets whose CI rule has become routine.
Worked example (synthetic TRB)
Sam's lab_scope.py uses only the ipaddress stdlib and documentation ranges; it never opens a socket.
Synthetic case — Riverstone Transit Bank (TRB). The bank, Sam Ito, TrackScope/FindingsDesk/PulseMap and all figures are invented for teaching.
Errors and limits
This book grants no authority to test real banks or payment systems. Labs use documentation-range addresses and synthetic data only; exploit code is never provided.
Exercises
- EX007 — Socket rule. Why must lab_scope open no sockets? Rubric: 3 = offline/synthetic only; no accidental scan; 2 = partial; 1 = sockets fine; 0 = none.
- EX008 — Two unsafe patterns. Name two scripting patterns forbidden on the platform team. Rubric: 3 = two of secrets, TLS off, unsanitised shell, uncapped retries; 2 = one; 1 = vague; 0 = none.
- EX009 — Second reader. What does the second reader look for? Rubric: 3 = scope path mistakes and secrets; 2 = one; 1 = style only; 0 = none.
Synthesis
Programming here means safe, reviewed, synthetic-first automation.
Continue studying — chapter 03 of 40
← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →