◇ OpenCyber Academy
Engineering · Chapter 46 · English

Chapter 46 — Engineering capstone II

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 46 — Engineering capstone II

Lesson map

Lesson 46 published. Map, example, EX136.

flowchart TD
  N0["Learning outcomes"]
  N1["46.1 Building to the baseline"]
  N2["46.2 Implementing controls"]
  N3["46.3 Evaluation harness"]
  N4["46.4 Defects and changes"]
  N5["46.4b Demonstrations and evidence"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX136"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["46.1 Building to the baseline"]
  N2["46.2 Implementing controls"]
  N3["46.3 Evaluation harness"]
  N4["46.4 Defects and changes"]
  N5["46.4b Demonstrations and evidence"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX136"]

[Learning outcomes]
    |
    v
[46.1 Building to the baseline]
    |
    v
[46.2 Implementing controls]
    |
    v
[46.3 Evaluation harness]
    |
    v
[46.4 Defects and changes]
    |
    v
[46.4b Demonstrations and evidence]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX136]

Learning outcomes

You will (1) build and integrate the capstone system to its approved baseline; (2) implement security controls and evaluation harnesses; (3) manage changes and defects; and (4) prepare for verification and the recovery trial.

46.1 Building to the baseline

Implement in increments, each ending with tests and a short demo. Keep requirements traceability current: each requirement points to code, configuration and tests. Use the CI security gate from Chapter 14 from the first increment.

Increments keep the gap between design and code small, so problems surface while they are cheap to fix. A demo at the end of each increment shows the client real progress and invites early feedback. Running the security gate from the start means the first version already has a baseline to compare against, rather than discovering many failures at once at the end.

46.2 Implementing controls

Implement the enforcement point, provenance handling, output validation, monitoring and supply-chain checks as separate, testable modules. Avoid "temporary" bypasses; if one is necessary for development, gate it behind configuration that cannot be enabled in the release build.

Separate modules let each control be tested and reviewed on its own, and replaced without disturbing the others. Temporary bypasses are a classic source of incidents: a flag that disables the enforcement point for local testing is harmless until it reaches production. Making the release build unable to enable it turns a promise into a check that the pipeline enforces.

46.3 Evaluation harness

Build the harness that runs held-out benign and adversarial suites, computes metrics with intervals and stores raw outputs. Include the independent adaptive-attack set provided by another team. Run it nightly and at each release candidate.

The adaptive set from another team is the most valuable part, because its authors did not know which attacks the design anticipated. Nightly runs catch regressions within a day of the change that caused them. Stored raw outputs let the team investigate a failure without rerunning the model, and support later questions from the panel.

46.4 Defects and changes

Track defects with severity; security defects block release until fixed or formally accepted with a risk owner. Changes to scope or requirements go through the change control agreed in Capstone I.

A formally accepted security defect names who accepted it, why and until when, so it does not become permanent by default. Blocking release on unfixed security defects can feel slow, but it prevents the common pattern of known weaknesses shipping because a deadline arrived. Scope changes during the build use the same process as before, keeping the baseline meaningful.

46.4b Demonstrations and evidence

End each increment with a short demonstration to the client that includes at least one adversarial case, not only the happy path. Save the demonstration script, inputs and outputs as evidence; they become part of the dossier in Chapter 48. Demonstrating a failure honestly, with the fix planned, builds more trust than a polished demo that hides it.

Bulletin Gate's demonstration after the schema change included one of the other team's adaptive bulletins: an instruction hidden in a maintenance note, now mapped to an enumerated category with no free text in the output. Showing the accuracy drop to 95.3% at the same demo was part of the honesty the panel looked for.

46.5 Worked example (synthetic NRS case)

During build, Bulletin Gate's quarantined model sometimes copied instruction-like sentences into a free-text "notes" field of its output schema. The schema was tightened: notes became an enumeration of predefined maintenance categories plus numeric fields. The adaptive set from the other team then produced zero instruction strings in outputs across 300 cases (95% upper bound ≈ 1%), while extraction accuracy fell from 96.4% to 95.3% — still meeting the requirement.

The fix was structural rather than a better filter: removing free text took away the place where instructions could hide.

46.6 Errors and limits

A free-text field in a supposedly structured output gives injected instructions a path through the quarantine, as the notes field showed. Development bypasses that ship turn a convenience into an open door. A harness run only at the end finds every problem at once, too late to fix them well. Sam's team kept the harness, the release-build check and the schema review in the definition of done for every increment.

Exercises

Synthesis

Capstone II builds the system as designed: incremental, traceable, gated by evaluation, with security defects treated as release blockers.

Continue studying — chapter 46 of 50

← Chapter 45 (draft) · Course chapter index · Chapter 47 (draft) →