Chapter 35 — Capstone proposal
Lesson map
Lesson 35 published. Map, example, EX103.
flowchart TD
N0["Learning outcomes"]
N1["35.1 Proposal"]
N2["35.2 Motivation"]
N3["35.3 Scope"]
N4["35.4 Success criteria"]
N5["35.5 Risks"]
N6["35.6 Mitigations"]
N7["35.7 Approval"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX103"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["35.1 Proposal"]
N2["35.2 Motivation"]
N3["35.3 Scope"]
N4["35.4 Success criteria"]
N5["35.5 Risks"]
N6["35.6 Mitigations"]
N7["35.7 Approval"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX103"]
[Learning outcomes]
|
v
[35.1 Proposal]
|
v
[35.2 Motivation]
|
v
[35.3 Scope]
|
v
[35.4 Success criteria]
|
v
[35.5 Risks]
|
v
[35.6 Mitigations]
|
v
[35.7 Approval]
|
v
[Worked example] --> [Exercise EX103]
Learning outcomes
You will (1) propose a capstone that improves StudyHub's cloud security; (2) define scope, method and success criteria; (3) identify risks; (4) obtain approval.
35.1 Proposal
Samuel proposes a "cloud posture report" for StudyHub: a weekly automated report combining registry, identity, logging, benchmark and pod security checks, with trends and owners, plus a secret scan in the build pipeline.
Each part of the proposal comes from earlier work: the registry review, account review, logging coverage, adapted benchmark and pod security checks already exist as separate scripts, and the secret scan follows the control register's gap. The capstone's contribution is to make them run together every week, in one place, with owners attached, so they keep working after the project ends.
35.2 Motivation
The opening case showed that no single view existed; the report gives one, and the scan addresses the root cause.
In the opening case, the registry setting, the image content and the logging gap were each visible to someone, but nobody saw all three together. A combined report would have placed them on one page. The scan goes further, because it stops a secret from reaching the registry at all, which removes the cause rather than detecting the result. Samuel states both aims in the proposal.
35.3 Scope
Read-only checks over exports; pipeline scan; report generation. Out of scope: automatic fixing.
Automatic fixing is excluded because a script that changes cloud settings needs much more testing and authority than a read-only report, and a wrong fix could break StudyHub during a deadline. Keeping the scope to reading and reporting also fits Samuel's project agreement, which grants read-only exports. Automatic fixing is listed as possible future work, with the conditions it would need: testing on synthetic accounts, approval from the cloud team and a clear rollback for every change it could make. Naming what is out of scope stops the project from growing during implementation.
35.4 Success criteria
All five check families running weekly; zero anonymous repositories; logging 6 of 6; findings median age under 14 days by term end; scan blocking any key-like string except allowed placeholders.
Each criterion can be checked with a number or a test at the end of term. Zero anonymous repositories and full logging coverage address the opening case directly. The fourteen-day median age comes from the remediation target in the statistics chapter, and the scan criterion has a specific exception so that test placeholders do not block builds.
35.5 Risks
Noise leading to ignored reports; scanner false positives blocking builds.
Both risks would undermine the project in the same way: people stop paying attention. A weekly report full of minor findings is quickly skimmed and then ignored, and a scanner that blocks builds for harmless test values would be bypassed or switched off. Each risk therefore has a specific mitigation. A third risk, delays in getting exports from the cloud team, is recorded in the risk log rather than the proposal, since it affects timing more than success. Each risk names who watches for it and what early sign would show it happening, such as owners not opening the report.
35.6 Mitigations
Owners and severity in the report; reviewed allow list for test placeholders.
Owners make each finding someone's job, and severity lets the summary show the few that matter most first. The allow list is reviewed so that it cannot quietly grow into a list of real secrets. Warning mode before blocking gives two weeks to tune the scanner on real builds without stopping anyone's work. Samuel also plans to ask the cloud team after a month whether the report is useful, so noise can be addressed before it causes the report to be ignored. Their answer, recorded in the evaluation chapter, led to the shorter summary at the top.
35.7 Approval
Tom and Dr Jensen approve, with Tom's team owning the report afterwards.
Approval by both Tom and Dr Jensen covers the operational and academic sides. Agreeing that Tom's team will own the report afterwards matters most for its future: a tool built by a student and owned by nobody would stop running within a term of graduation. The approval is recorded in the project log with the date and both names, and it lists the success criteria exactly as written above. Any later change to scope or criteria needs the same two approvals, recorded in the same place, so the final evaluation can be compared fairly with what was agreed at the start.
Plan and timeline
The capstone runs over ten weeks: two weeks design, four implementation, two verification, two documentation and handover. Weekly check-ins with Tom keep it aligned with the cloud team's priorities. A risk log tracks issues such as delays in getting exports. Samuel builds in a buffer week, which he later needs when an export format changes. He also schedules a mid-point demonstration to developers to collect feedback while there is still time to act on it.
Supervision
Dr Jensen reviews progress fortnightly against the plan.
Handover owner
Tom's team names an owner for the report before work begins.
Worked example
Dr Jensen asks Samuel to state what he will not claim: the report shows configuration state, not that StudyHub cannot be attacked. Samuel adds this to the proposal's limits section.
Synthetic case. Proposal is synthetic.
Errors and limits
Capstones should solve a real problem, not showcase tools.
Exercises
- EX103 — Capstone. What is the capstone? Rubric: 3 = weekly posture report plus pipeline secret scan; 2 = partial; 1 = vague; 0 = none.
- EX104 — Criteria. Name two success criteria. Rubric: 3 = weekly checks, no anonymous repos, logging 6/6, median <14 d, scan blocks keys; 2 = one; 1 = vague; 0 = none.
- EX105 — Limit stated. What will Samuel not claim? Rubric: 3 = that StudyHub cannot be attacked; 2 = partial; 1 = vague; 0 = none.
Synthesis
A good capstone solves a real problem with clear criteria and limits.
Continue studying — chapter 35 of 40
← Chapter 34 (draft) · Course chapter index · Chapter 36 (draft) →