Chapter 18 — Supervised technical project
Lesson map
Lesson 18 published. Map, example, EX069.
flowchart TD
N0["Learning outcomes"]
N1["18.1 The project"]
N2["18.2 Work done"]
N3["18.3 Measurement"]
N4["18.5 Presentation"]
N5["18.6 Next steps"]
N6["Training others"]
N7["Reflection"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX069"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["18.1 The project"]
N2["18.2 Work done"]
N3["18.3 Measurement"]
N4["18.5 Presentation"]
N5["18.6 Next steps"]
N6["Training others"]
N7["Reflection"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX069"]
[Learning outcomes]
|
v
[18.1 The project]
|
v
[18.2 Work done]
|
v
[18.3 Measurement]
|
v
[18.5 Presentation]
|
v
[18.6 Next steps]
|
v
[Training others]
|
v
[Reflection]
|
v
[Worked example] --> [Exercise EX069]
Learning outcomes
You will (1) deliver a supervised improvement project; (2) apply the course; (3) measure the result; (4) present it with limits.
18.1 The project
Tomás's project is to reduce the time from advisory publication to all affected customer sites being updated. Before the course, Pinecrest had no inventory; the Ferncroft-type cases were found by customer complaints. The goal is measurable and comes directly from the opening case, where weeks passed before customer complaints revealed the Ferncroft redirects. Reducing the time from advisory to update tests the whole course: inventory, verification, procedures and automation must all work for the figure to improve. Grace supervises the project at Pinecrest and his college tutor assesses it for the course.
18.2 Work done
The nightly inventory and advisory comparison, the installation and update procedures with hash or signature verification, the header baseline, file-change monitoring and the removal of unused plugins. Each item answers one of the four Ferncroft gaps: procedures with verification replace mirror downloads, the baseline and permission checks address misconfiguration, and the nightly inventory makes outdated components visible. Removing unused plugins shrinks what the inventory and advisory comparison must track each night. None of the items changes customer sites automatically, keeping the read-only rule intact. Each item is documented in the support knowledge base with its owner.
18.3 Measurement
Over three months, Tomás measures median time from advisory to update for high advisories: 5 days across 24 high advisories. Before the project there was no reliable record, so he compares with the Ferncroft case, where weeks passed before anyone noticed. A median of 5 days sits inside the 7-day target for high advisories. Tomás reports the median rather than the average, so a few slow updates do not hide the typical result. All 24 advisories and their update dates come from tickets, which Grace can check.
18.4 Limits
The before figure is weak evidence; customer-chosen plugins outside the advisory feeds are not covered; vendor compromises can only be detected, not prevented. Stating these three limits openly keeps the presentation honest about what the figures show. The Ferncroft comparison is one case, not a measured baseline, so it shows the direction of change but not its size. Plugins outside the feeds can only be covered by adding sources, and vendor compromise still depends on detection such as file-change monitoring. The tutor asks Tomás to state these limits in the written report as well.
18.5 Presentation
Tomás presents to Grace and his college tutor with evidence from tickets and nightly reports, mapping the work to the SSDF practice groups for responding to vulnerabilities and protecting software. Mapping the work to SSDF practice groups shows that a consumer's routine can follow the same framework producers use, adapted to Pinecrest's role. Evidence from tickets and nightly reports lets Grace and the tutor check each claim, such as the 5-day median, against records rather than Tomás's description of them.
18.6 Next steps
Add vendor signature checks where offered and extend the inventory to bundled libraries via SBOMs. Both of these next steps extend checks that the project already performs every night. Signature checks strengthen the verification step for vendors that publish signatures, as the new technician found, and SBOMs extend the inventory beyond plugins to the libraries bundled inside them. Each will need the same synthetic tests and procedure updates before use. Both are scheduled with owners and dates in Pinecrest's plan for the next year.
Training others
Training the two new technicians tests the documents again: each follows the procedures on the test copies while Tomás watches without helping. Their questions lead to three small edits. By the end of the week both complete an installation and an update correctly, and Grace signs them off for live work.
Reflection
Tomás writes that the most useful habit was checking sources before installing anything.
Worked example
The project is assessed as complete. Pinecrest keeps the nightly job and procedures in service, and Grace asks Tomás to train two new technicians on them.
Synthetic case. People and results are synthetic.
Errors and limits
Report weak comparisons honestly rather than overstating improvement.
Exercises
- EX069 — Project goal. What was the project goal? Rubric: 3 = reduce advisory-to-update time; 2 = partial; 1 = vague; 0 = none.
- EX070 — Measure. What was measured? Rubric: 3 = median 5 days for 24 highs; 2 = partial; 1 = vague; 0 = none.
- EX071 — Limits. Name two limits. Rubric: 3 = weak before figure; plugins outside feeds; vendor compromise; 2 = one; 1 = vague; 0 = none.
- EX072 — Next steps. What are the next steps? Rubric: 3 = signatures; SBOMs for bundled libraries; 2 = partial; 1 = vague; 0 = none.
Synthesis
Deliver, measure and present with honest limits.
Continue studying — chapter 18 of 18
← Chapter 17 (draft) · Course chapter index · Worked results ↓ · Next course via chapter index →