◇ OpenCyber Academy
Technologist · Chapter 29 · English

Chapter 29 — Capstone build

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 29 — Capstone build

Lesson map

Lesson 29 published. Map, example, EX057.

flowchart TD
  N0["Learning outcomes"]
  N1["29.1 Scope"]
  N2["29.2 Build order"]
  N3["29.3 Reproducibility"]
  N4["29.4 Decision records"]
  N5["29.6 Practical activity"]
  N6["29.7 Security of the build"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX057"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["29.1 Scope"]
  N2["29.2 Build order"]
  N3["29.3 Reproducibility"]
  N4["29.4 Decision records"]
  N5["29.6 Practical activity"]
  N6["29.7 Security of the build"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX057"]

[Learning outcomes]
    |
    v
[29.1 Scope]
    |
    v
[29.2 Build order]
    |
    v
[29.3 Reproducibility]
    |
    v
[29.4 Decision records]
    |
    v
[29.6 Practical activity]
    |
    v
[29.7 Security of the build]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX057]

Learning outcomes

You will (1) build a complete migrated slice of a service in a lab; (2) integrate inventory, configuration, automation, monitoring and runbooks; (3) keep everything reproducible; and (4) document decisions.

29.1 Scope

Choose one KLS-like flow end to end with at least three hops. Deliver: lab infrastructure as code; inventory entries and trace; central crypto profile applied at each hop; CI gate; negotiation logging and dashboard; runbooks; exception and residual-risk register; evaluation data.

Three hops is the minimum because the capstone must show that every termination is configured and evidenced, not just one. Every deliverable lives in one repository, and assessors judge the slice as a whole: a perfect profile with no monitoring is incomplete.

29.2 Build order

Lab infrastructure → inventory and trace → profile → automation gate → monitoring → runbooks → evaluation. Commit at each step with a short decision record.

The order follows dependencies: nothing can be inventoried before the lab exists, the profile needs the inventory to know where it applies, the gate needs the profile to check against, and monitoring needs a running profile to observe. Runbooks need monitoring to name symptoms, and evaluation needs all of it. Each step ends with a commit and a short decision record, so the repository history tells the story of the build. Teams that start with the dashboard usually rebuild it later.

29.3 Reproducibility

Anyone should be able to clone the repository, run one command to build the lab, and reproduce the dashboard numbers from logged runs. Pin versions; fix random seeds for synthetic data.

The test is literal: an assessor runs the build command on a clean machine. Pin package and image versions by digest, keep lab keys generated at build time, and store recorded session logs so the dashboard can be rebuilt from them. A random seed fixed in the synthetic data generator makes the numbers identical on every rebuild, which is what lets an assessor compare them with the report.

29.4 Decision records

Record decisions such as "ML-KEM-768 hybrid rather than ML-KEM-1024 because policy requires category 3 and RFC 10024's group uses -768" or "classical certificates retained because relying-party library X lacks ML-DSA".

A decision record has context, options considered, the decision and its consequences, and is dated. KLS-style examples also include the evidence behind the decision, such as the lab record showing a relying party failing ML-DSA validation, and the condition that would reopen it. Records are short; their value is that a later team can see why something is the way it is.

29.5 Worked example

Capstone (synthetic): partner SFTP via a bastion and an internal file processor. Build: Terraform-style lab scripts, OpenSSH with hybrid KEX first, an audit script in CI checking KexAlgorithms, log parser feeding a dashboard of KEX share, runbooks for no_shared_group and fallback, exception for an emulated legacy partner client. Evaluation data from 3,000 sessions across six client types.

The six client types match the studio's partner matrix, so the evaluation reuses its known results. The exception for the legacy client shows the full exception record in practice, and the 3,000 sessions are enough to give a meaningful upper bound on failures.

29.6 Practical activity

Create your capstone repository with the build order as milestones.

Create one milestone per build-order step, with the artefact that closes it: lab build script, inventory and trace files, profile, CI gate, logging and dashboard, runbooks and evaluation data. Add a README stating the flow, the hops and how to build. Open an issue for each known unknown, such as a client type you cannot emulate, so it is tracked from the start rather than discovered at assessment.

For the SFTP slice, the profile milestone links to the record choosing the hybrid group and the record listing which partner clients stay classical, so an examiner can see why the gate allows them.

29.7 Security of the build

Treat the capstone repository as production-grade: no real secrets committed, lab keys generated at build time, access limited to the team and assessors, and dependency versions pinned. Include a short threat note for the lab itself — what an attacker could do with the repository and how you prevented it. Assessors will look for this, and it is a habit worth keeping.

KLS assessors check the history for committed keys with a secret scanner.

They also confirm that lab keys are regenerated on each build, so a leaked key from an old clone is useless.

29.8 Common errors and limits

A capstone built by hand on a lab machine cannot be rebuilt by the assessor, so its numbers cannot be checked. A capstone without the CI gate leaves the demonstration's "gate blocks a bad change" step impossible and loses the automation criterion. And undocumented decisions, such as why host keys stayed classical, turn into examiner questions the student cannot answer with evidence. These three account for most lost marks.

Exercises

Synthesis

The capstone build integrates every implementation skill into one reproducible, documented, secure lab slice ready for assessment.

Continue studying — chapter 29 of 30

← Chapter 28 (draft) · Course chapter index · Chapter 30 (draft) →