◇ OpenCyber Academy
Engineering · Chapter 39 · English

Chapter 39 — Authorized offensive security and red team: maintainability

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 39 — Authorized offensive security and red team: maintainability

Lesson map

Lesson 39 published. Map, example, EX115.

flowchart TD
  N0["Learning outcomes"]
  N1["39.1 Churn"]
  N2["39.2 Thin adapters"]
  N3["39.3 Ownership"]
  N4["39.2b Dependency risk"]
  N5["39.3b Deletion plan"]
  N6["39.1b API deprecation windows"]
  N7["Practice note"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX115"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["39.1 Churn"]
  N2["39.2 Thin adapters"]
  N3["39.3 Ownership"]
  N4["39.2b Dependency risk"]
  N5["39.3b Deletion plan"]
  N6["39.1b API deprecation windows"]
  N7["Practice note"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX115"]

[Learning outcomes]
    |
    v
[39.1 Churn]
    |
    v
[39.2 Thin adapters]
    |
    v
[39.3 Ownership]
    |
    v
[39.2b Dependency risk]
    |
    v
[39.3b Deletion plan]
    |
    v
[39.1b API deprecation windows]
    |
    v
[Practice note]
    |
    v
[Worked example] --> [Exercise EX115]

Learning outcomes

You will (1) budget for policy and dependency updates; (2) keep adapters thin; (3) document ownership.

39.1 Churn

ATT&CK techniques, IdP APIs and ROE templates change. Budget calendar time for updates; pin versions and watch advisories.

Dependencies that move every week force TrackScope into permanent firefighting. Pinning versions and reviewing upgrades as changes, not as background noise, keeps fail-closed behaviour testable. Sam's dependabot rules require a Lab I green on safety rows before a pin moves. Pins that sit behind safety rows cannot use the ordinary dependency train without that green. Ordinary library bumps that do not touch safety rows may still use the weekly train.

39.2 Thin adapters

Isolate third-party SDKs behind interfaces so upgrades do not rewrite FindingsDesk core.

A thick wrapper around a scanner invites unreviewed behaviour when the scanner updates. Thin adapters that only translate results into FindingsDesk schema keep the dangerous logic outside the trust boundary you maintain. Sam's adapter for the name-similarity check is under two hundred lines and has no shell-out. When the upstream scanner added a "auto-exploit" flag, the thin adapter ignored it and never exposed a switch in TrackScope. The adapter's tests include a fixture where the upstream flag is true and assert FindingsDesk never sees it.

39.3 Ownership

Every service has a named owning squad and a backup. CODEOWNERS enforces review.

Synthetic case — Riverstone Transit. PulseMap's ATT&CK mapper is an adapter; upgrading the technique list is a data PR, not a rewrite.

CODEOWNERS on safety paths means a merge cannot land without someone who understands deny semantics. Orphan modules are how fail-open returns after a refactor. Sam's review of a "cleanup" PR that touched allowed() required two safety owners, not one casual approve. The cleanup author had to pair with a safety owner before the merge button enabled.

39.4 Errors and limits

Orphan tools rot into fail-open museums.

Abandoned tools still appear in ROE text and mislead the next lead. A yearly prune of the catalogue, with ROE templates updated in the same change, is maintenance, not housework. Sam removed three method cards last year whose binaries were no longer on the jump image. ROE templates that still named them failed a lint until the strings were removed in the same change. Catalogue prune and ROE lint share one pull request so they cannot drift a week apart.

39.2b Dependency risk

Track libraries that parse CIDRs, YAML policy, or crypto. An RCE in a policy parser is a fail-open incident waiting to happen — pin, monitor CVEs, and prefer small parsers under your tests.

A library that parses host strings sits on the fail-closed path; its CVEs are engagement blockers, not backlog trivia. Sam tracks those libraries on a short list next to the predicate and pages on new advisories the same day. An advisory on the host-parser library last quarter blocked two engagements until the pin moved and Lab I re-ran.

39.3b Deletion plan

Maintainability includes knowing how to retire a tool: export dossiers, revoke credentials, archive code, mark PulseMap sources deprecated. Orphan services attract unowned risk.

Deleting a service without a date leaves ghost event types on the bus. The deletion plan names consumers, the last engagement that may use it, and the purge of its secrets. Sam's PulseMap-v1 retirement date sat on the calendar beside the ROE that still cited it, until both changed together. Secrets for the retired service were rotated on the purge date, not left "in case we roll back."

39.1b API deprecation windows

Announce deprecations with dates; keep dual-run periods for PulseMap consumers. Sudden removals of reason codes break timelines mid-engagement.

Clients need calendar time before /v1/ goes dark. A deprecation window with dual-run and a named end date beats a surprise 404 during a client engagement. Sam announced FindingsDesk field retirements ninety days out and failed CI for new callers of the old names after day thirty. Mobile clients that still called the old field received a dedicated error code pointing at the migration guide.

Practice note

Write a bus-factor note for each service: who can release, who understands the predicate, who can restore the sealed store. If the answer is one person, schedule cross-training before the next engagement season. Maintainability is mostly about people who are allowed to be on holiday.

Calendar a dependency upgrade month each year so CVE pins do not wait for an emergency.

Ownership pages list vacation coverage by name, not by squad alias.

Treat missing vacation coverage as a release blocker equal to a failing test.

Cross-training sessions use the same synthetic fixtures as Lab I so teaching time also refreshes verification muscle.

39.4b Documentation as maintenance

Every module in the platform has a short README stating its purpose, owner, inputs, outputs and the tests that guard it. Sam updates these in the same pull request as code changes; reviewers reject changes that leave the README describing behaviour that no longer exists.

A runbook that describes buttons the UI no longer has is worse than none. Doc changes ride in the same pull request as the UI change, reviewed by an operator who was not the author. Sam's last UI rename was blocked until the offline binder page was updated and re-hashed.

Exercises

Synthesis

Pins, adapters and named owners keep tools alive safely.

Continue studying — chapter 39 of 50

← Chapter 38 (draft) · Course chapter index · Chapter 40 (draft) →