Chapter 30 — Capstone assessment
Lesson map
Lesson 30 published. Map, example, EX088.
flowchart TD
N0["Learning outcomes"]
N1["30.1 Presentation"]
N2["30.2 Evidence"]
N3["30.3 Questions"]
N4["30.5 Reflection"]
N5["30.6 Next steps"]
N6["Feedback received"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX088"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["30.1 Presentation"]
N2["30.2 Evidence"]
N3["30.3 Questions"]
N4["30.5 Reflection"]
N5["30.6 Next steps"]
N6["Feedback received"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX088"]
[Learning outcomes]
|
v
[30.1 Presentation]
|
v
[30.2 Evidence]
|
v
[30.3 Questions]
|
v
[30.5 Reflection]
|
v
[30.6 Next steps]
|
v
[Feedback received]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX088]
Learning outcomes
You will (1) present the capstone; (2) show evidence; (3) answer questions; (4) reflect on learning and next steps.
30.1 Presentation
Diego presents to Aiko and a Southport Polytechnic tutor: the January problem, the controls built, the evidence that they work, and the SBOM capstone. The presentation follows the course order: the problem first, then each control with its evidence, then the capstone and its limits. Diego keeps to synthetic records throughout, so no client data appears on the slides. The tutor and Aiko assess the presentation together, each using the course rubric, and compare their scores afterwards. Diego's talk lasts twenty minutes, leaving time for questions about evidence and limits.
30.2 Evidence
He shows the nightly reports, the validation records for 23 projects, the field-practice timeline and the SBOM tests, all from synthetic records. Each piece of evidence matches one of the three placement goals. Nightly reports and the field timeline show the inventory answering in minutes and highs fixed within seven days; validation records and digest records show deployments were recorded pipeline builds. Each piece of evidence is a record produced during normal work, not a document prepared for the assessment. He brings the raw records so any figure on a slide can be checked on request.
30.3 Questions
The tutor asks how the work fits the SSDF. Diego maps it: inventory and audits to Respond to Vulnerabilities; pipeline template and pinning to Protect the Software; upload checks and reviews to Produce Well-Secured Software; runbooks and roles to Prepare the Organization. The tutor follows up by asking which group was weakest at the start, and Diego names Respond, as the January search showed. The mapping shows that each group gained at least one concrete control during the placement. He adds that the map came from the SSDF table used to set the placement goals.
30.4 Limits
He names the limits honestly: two legacy projects remain, SBOMs are unsigned and unknown flaws are not found by audits. Naming limits shows the assessors what the evidence does not cover yet. The two legacy projects still rely on compensating steps until their rebuild, unsigned SBOMs could be altered without detection, and audits find only flaws that already have advisories. Diego also notes that the field event was a single event, so it shows the process can work rather than that it always will.
30.5 Reflection
Diego writes that the biggest lesson was that most security work is careful routine: keeping lists current, watching checks and fixing small problems before they grow. Diego's reflection links this lesson to specific moments: the four-minute test advisory, the missed lockfiles caught by the missing-project count, and the eleven handoff questions turned into runbook steps. None of these was dramatic, but each kept a control working. Diego also notes that the routine only worked because each control had a named owner.
30.6 Next steps
Brightwave will rebuild the legacy projects, aim for SLSA build L3 and add signed SBOMs. Each next step answers one named limit: the rebuild for the two legacy projects, SLSA L3 for build hardening, and signed SBOMs. Diego hands these to their owners with target dates in the monthly report, and the tutor's suggestion to count SBOM requests is added to the same report. The next placement student will start from these targets and the existing runbooks. Each next step names the limit it closes and the evidence that would show success.
Feedback received
The tutor's feedback praises the evidence and the honest limits, and suggests that the next step should include measuring how often clients use their SBOMs, since an unused document adds work without value. Aiko adds that the handoff quality was the strongest part, because the processes kept running without Diego during the watched fortnight. Diego records both points in his learning log and adds an SBOM-request count to the monthly report. Looking back over the year, he notes how each chapter's small step depended on earlier ones: the inventory made audits possible, audits made fix targets measurable, and records made the capstone possible.
Worked example
The capstone is assessed as complete with distinction, and Brightwave offers Diego a junior developer role starting after graduation, with security processes as part of his responsibilities.
Synthetic case. People, results and outcomes are synthetic.
Errors and limits
Assessment rewards honest limits as well as results.
Exercises
- EX088 — SSDF map. Map the work to the SSDF groups. Rubric: 3 = four groups mapped; 2 = three; 1 = one; 0 = none.
- EX089 — Limits. Name two limits. Rubric: 3 = legacy projects; unsigned SBOMs; unknown flaws; 2 = one; 1 = vague; 0 = none.
- EX090 — Lesson. What was Diego's main lesson? Rubric: 3 = security is careful routine; 2 = partial; 1 = vague; 0 = none.
Synthesis
Present evidence, map it to frameworks and name the limits.
Continue studying — chapter 30 of 30
← Chapter 29 (draft) · Course chapter index · Worked results ↓ · Next course via chapter index →