Chapter 25 — Team project studio

Chapter 25 — Team project studio

Lesson map

Lesson 25 published. Map, example, EX073.

flowchart TD
  N0["Learning outcomes"]
  N1["25.1 The project"]
  N2["25.2 Roles and tracking"]
  N3["25.3 Security review"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX073"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["25.1 The project"]
  N2["25.2 Roles and tracking"]
  N3["25.3 Security review"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX073"]

[Learning outcomes]
    |
    v
[25.1 The project]
    |
    v
[25.2 Roles and tracking]
    |
    v
[25.3 Security review]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX073]

Learning outcomes

You will (1) plan a team project on trust services; (2) divide roles and track work; (3) review each other's work for security.

25.1 The project

Rosa's studio team of four is assigned to build an internal dashboard showing certificate health for the council, using inventory and monitoring data. The team agrees on scope: read-only views of expiry, renewal status and TLS findings; no ability to change systems. Restricting scope reduces risk, since a dashboard that could trigger actions would need far stronger controls. They write a one-page project charter with goals, scope, roles and a schedule of four two-week iterations. The charter also lists what is out of scope, so requests for new features can be declined politely by pointing to it.

25.2 Roles and tracking

Roles rotate: one person leads data integration, one the interface, one testing and one documentation and security review. They track tasks on a shared board and hold short weekly check-ins. When one teammate falls behind due to exams, the team reassigns tasks openly rather than letting work silently slip. Rosa finds that writing down decisions, such as which data sources are trusted, avoids repeated debates later. Each iteration ends with a short demo to Owen, whose comments shape the next plan. When disagreements arise, the team records options and the reason for the choice in a decision log, which later helps new members understand why the dashboard works as it does.

25.3 Security review

Each change gets a review by another teammate using a checklist: authentication required, data sources read with least privilege, no secrets in code, dependencies pinned and output that does not leak internal hostnames publicly. Reviewers find a hard-coded API token in an early commit; the team rotates the token and rewrites the history in the private repository, then adds a secret scanner. They learn that rotating the exposed secret matters more than hiding it. The scanner now runs on every push, and the team adds a short note to their charter about handling any future leak.

Worked example

Rosa's team builds a read-only certificate dashboard over four iterations and, after finding a hard-coded token, rotates it and adds secret scanning.

Synthetic case. The team and project are invented.

Errors and limits

Removing a leaked secret from history does not make it safe; rotate it. Rotating roles needs handover notes.

Exercises

• EX073 — Scope choice. Why was the dashboard kept read-only? Rubric: 3 = actions would require far stronger controls; reduces risk;; 2 = risk;; 1 = easier;; 0 = none.
• EX074 — Token finding. What did the team do after finding a hard-coded token? Rubric: 3 = rotated it, cleaned history, added secret scanner;; 2 = rotate;; 1 = delete only;; 0 = none.
• EX075 — Lesson. What matters most after a secret leaks? Rubric: 3 = rotating the secret;; 2 = rotate;; 1 = hide;; 0 = none.

Synthesis

Team projects succeed with limited scope, open tracking and peer security reviews that act on findings.

Continue studying — chapter 25 of 30

← Chapter 24 (draft) · Course chapter index · Chapter 26 (draft) →