Chapter 36 — Field or community practice
Lesson map
Lesson 36 published. Map, example, EX106.
flowchart TD
N0["Learning outcomes"]
N1["36.1 The setting"]
N2["36.2 What she finds"]
N3["36.3 What she does"]
N4["36.4 Teaching"]
N5["36.5 Boundaries"]
N6["36.6 Reflection"]
N7["Agreement"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX106"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["36.1 The setting"]
N2["36.2 What she finds"]
N3["36.3 What she does"]
N4["36.4 Teaching"]
N5["36.5 Boundaries"]
N6["36.6 Reflection"]
N7["Agreement"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX106"]
[Learning outcomes]
|
v
[36.1 The setting]
|
v
[36.2 What she finds]
|
v
[36.3 What she does]
|
v
[36.4 Teaching]
|
v
[36.5 Boundaries]
|
v
[36.6 Reflection]
|
v
[Agreement]
|
v
[Worked example] --> [Exercise EX106]
Learning outcomes
You will (1) apply application security skills in a community setting; (2) support other projects responsibly; (3) teach secure practices; (4) reflect on community work.
36.1 The setting
Lena volunteers with a local charity that runs a food-bank booking website built by volunteers. Under a written agreement with the charity, she helps review its development practices, not to test live systems without permission.
The agreement names the charity's coordinator as her contact, lists what she may look at, such as the code repository, hosting settings and dependency files, and excludes anything containing client information. Lena brings the habits she learned at CampusEats, but she knows the charity's needs and resources are different, so she starts by listening to how the volunteers actually work.
36.2 What she finds
The site's repository is private but shared with many past volunteers; three still have write access. Dependencies have not been updated for a year; two have high-severity advisories. A database password is stored in a configuration file in the repository.
Lena reports these to the coordinator in plain language, ranking them by how much harm each could cause and how easy each is to fix. The password in the repository is the most urgent, since anyone with old access could read it, and it echoes the token leak at CampusEats. She does not try to check whether anyone has misused the access, since that falls outside her agreement.
36.3 What she does
She helps the charity remove old access, move the password to the hosting platform's secret settings and rotate it, and set up an update bot. She explains each step so volunteers can continue.
Each change is made by a charity volunteer with Lena watching, so the volunteers know how to repeat it. The two vulnerable dependencies are updated through the bot's first pull requests, and the site is tested together before deployment. Lena writes a one-page note listing what changed, why and who now owns each task, so the work does not depend on her staying involved.
36.4 Teaching
Lena runs a two-hour workshop for the charity's volunteers on secrets, updates and access, using the CampusEats case cards.
The workshop uses real examples from CampusEats, with names removed, so volunteers see that the same problems happen elsewhere and are not a sign of carelessness. Each part ends with a short exercise on the charity's own setup, such as checking who has access to the repository. Lena asks for feedback at the end and adjusts the cards for future use.
36.5 Boundaries
Lena does not access the food bank's client data; she works only on code and configuration with the charity's coordinator present.
Keeping to these limits protects the charity's clients, many of whom are in difficult circumstances, and it protects Lena from handling data she has no reason to see. When a configuration question would have required looking at a database table, she asked a charity volunteer to check the structure instead. She records each session's activities in her placement log.
36.6 Reflection
Lena notes that small organisations need simple, sustainable practices more than advanced tools.
The charity has no budget, little time and volunteers who change often. Signing and provenance would add little for its site; removing old access, moving a secret and automating updates removed most of the risk in an afternoon. Lena's log records this as the main lesson of the placement, and she later uses it when designing the starter template, which aims for simple defaults rather than every possible control.
Agreement
The written agreement states the purpose, what Lena may access, who supervises, and that she will not keep copies of any code or data. Both Lena and the charity's coordinator sign it, and Grace reviews it to make sure it protects the charity and Lena.
Worked example
Three months later the charity's coordinator reports that the update bot has merged 14 updates and that new volunteers now receive access only for the duration of their project. Lena's community report becomes part of her course portfolio.
Synthetic case. The charity and findings are synthetic.
Errors and limits
Volunteer help must not create dependency on one person; leave documentation and owners.
Exercises
- EX106 — Three findings. List the three findings at the charity. Rubric: 3 = old write access; outdated deps with advisories; password in repo; 2 = two; 1 = one; 0 = none.
- EX107 — Boundaries. What boundaries did Lena keep? Rubric: 3 = no client data; code/config only; coordinator present; 2 = partial; 1 = vague; 0 = none.
- EX108 — Outcome. What was the outcome after three months? Rubric: 3 = 14 updates merged; time-limited access; 2 = partial; 1 = vague; 0 = none.
Synthesis
Community practice means simple, sustainable improvements within clear boundaries.
Continue studying — chapter 36 of 40
← Chapter 35 (draft) · Course chapter index · Chapter 37 (draft) →