Chapter 29 — Capstone build
Lesson map
Lesson 29 published. Map, example, EX085.
flowchart TD
N0["Learning outcomes"]
N1["29.1 The capstone"]
N2["29.2 Integration"]
N3["29.3 Tests"]
N4["29.4 Build log"]
N5["29.5 Scope discipline"]
N6["29.6 Safety rules"]
N7["29.7 Code review"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX085"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["29.1 The capstone"]
N2["29.2 Integration"]
N3["29.3 Tests"]
N4["29.4 Build log"]
N5["29.5 Scope discipline"]
N6["29.6 Safety rules"]
N7["29.7 Code review"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX085"]
[Learning outcomes]
|
v
[29.1 The capstone]
|
v
[29.2 Integration]
|
v
[29.3 Tests]
|
v
[29.4 Build log]
|
v
[29.5 Scope discipline]
|
v
[29.6 Safety rules]
|
v
[29.7 Code review]
|
v
[Worked example] --> [Exercise EX085]
Learning outcomes
You will (1) build a capstone CTI pipeline end to end on synthetic data; (2) integrate earlier labs into one tested system; (3) keep a build log; (4) meet a fixed scope by a deadline.
29.1 The capstone
Lena's capstone: an "MCX-to-CMS pipeline" that imports a synthetic STIX bundle, refangs and validates values, deduplicates with provenance, stores them with TLP labels, matches a synthetic DNS log, flags expiries and produces the weekly note and a TLP-filtered export for MCX feedback.
The pipeline joins the labs of the book in the order data flows at CMS: the STIX bundle from chapter 4, refanging and validation from chapter 3, deduplication from chapter 12, matching from chapter 15 and expiry flagging from chapter 19. The weekly note and export add the dissemination steps of the intelligence cycle.
29.2 Integration
Each earlier lab becomes a module with clear inputs and outputs. A single runner calls them in order and stops with a clear message if any stage fails.
Clear inputs and outputs let each module be tested and replaced alone. If the matcher changes, as in the worked example, the deduplicator does not need to. Stopping with a message on failure prevents later stages running on bad data, for example exporting indicators that were never validated. The runner prints which stage is running, so a failure is easy to place even before reading the error message.
29.3 Tests
Each module keeps its lab test cases; an end-to-end test checks the whole run against expected outputs: three unique indicators, two hosts with hits, two expiry flags, one dangling relationship reported.
The end-to-end figures come straight from the lab outputs: three unique indicators from deduplication, two hosts with hits from matching, two expiry flags from the expiry lab and one dangling relationship from the STIX lab. If any number changes, a module has changed behaviour, and the test points to which one.
29.4 Build log
Daily entries: what was built, decisions and reasons, problems. The log becomes an appendix.
Recording reasons as well as decisions helps assessors understand choices that might otherwise look odd, such as stopping on any failure rather than skipping a bad stage. Problems recorded daily, like the matcher fault in the worked example, show how Lena found and fixed them. As an appendix, the log is part of the assessed evidence. Entries are short and dated, so the log can be read quickly by an assessor checking a particular decision.
29.5 Scope discipline
Features beyond the brief — a web dashboard, a chat bot — go to a "later" list. The deadline holds.
A web dashboard or chat bot might impress, but neither is in the brief, and either would take time from tests and documentation. The later list keeps ideas without letting them threaten the deadline. It also feeds the transition plan, because some ideas may be worth building once the pipeline proves itself at CMS. Each later item records why it was deferred, so the reasoning is clear when the list is revisited after assessment.
29.6 Safety rules
No network calls, no real data, standard library only. The export filter refuses anything not CLEAR or GREEN and any unknown label.
Refusing unknown labels is the important detail: a typo such as GRENE should not be treated as GREEN. Failing closed means a mistake stops an item from being shared rather than letting it through. No network calls and no real data keep the capstone safe to run anywhere, including on assessors' machines. The tests include an item with an unknown label, so the refusal is checked every time the pipeline runs.
29.7 Code review
The tutor and one peer review the code before submission, focusing on clarity, error handling and the export filter.
The export filter gets special attention because it is the one part whose failure could share restricted data outside CMS. Clarity and error handling matter because the code may later be maintained by someone else. Review comments and Lena's responses become part of the evidence assessors see. Lena responds to each comment in writing, either with a change or with a reason for leaving the code as it is. The peer reviewer is a classmate who did not work on the pipeline, so the review comes from someone reading the code fresh.
29.8 Packaging
A README explains how to run the pipeline and tests in one command each, so assessors can reproduce results.
One command for the pipeline and one for the tests means an assessor does not need to understand the design to check that it works. If results differ on their machine, the README's description of the expected output shows what should have appeared, so a reproduction problem is easy to spot. The README also lists the expected test output, so a result that differs on an assessor's machine is noticed at once.
Error messages
When a stage fails, the message names the stage, the input file and the offending line, so the operator can act without reading code.
Worked example
The end-to-end test fails: two hosts expected, three reported. Lena traces it to the matcher reading a new log column. She fixes the parser, reruns, and records the cause in the build log.
Synthetic case. The pipeline and data are invented teaching material.
Errors and limits
A capstone proves design on synthetic inputs; production needs validation on real data.
Exercises
- EX085 — Module chain. List the pipeline stages in order. Rubric: 3 = import, refang/validate, dedupe, store, match, expiry, report/export; 2 = most; 1 = few; 0 = none.
- EX086 — Export filter. What does the export filter refuse? Rubric: 3 = anything not CLEAR/GREEN and unknown labels; 2 = one; 1 = vague; 0 = none.
- EX087 — Failing test. What caused the end-to-end test failure and how was it recorded? Rubric: 3 = new log column misread; parser fixed; logged; 2 = partial; 1 = ignored; 0 = none.
Synthesis
Integrate tested modules, log decisions, hold scope, keep safety rules and make results reproducible.
Continue studying — chapter 29 of 30
← Chapter 28 (draft) · Course chapter index · Chapter 30 (draft) →