◇ OpenCyber Academy
Technologist · Chapter 27 · English

Chapter 27 — Deployment and validation

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 27 — Deployment and validation

Lesson map

Lesson 27 published. Map, example, EX079.

flowchart TD
  N0["Learning outcomes"]
  N1["27.1 Rollout plan"]
  N2["27.2 Validation tests"]
  N3["27.3 Recording results"]
  N4["27.4 Projects that cannot comply"]
  N5["27.5 Rollback"]
  N6["27.6 Communicating"]
  N7["Validation as a habit"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX079"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["27.1 Rollout plan"]
  N2["27.2 Validation tests"]
  N3["27.3 Recording results"]
  N4["27.4 Projects that cannot comply"]
  N5["27.5 Rollback"]
  N6["27.6 Communicating"]
  N7["Validation as a habit"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX079"]

[Learning outcomes]
    |
    v
[27.1 Rollout plan]
    |
    v
[27.2 Validation tests]
    |
    v
[27.3 Recording results]
    |
    v
[27.4 Projects that cannot comply]
    |
    v
[27.5 Rollback]
    |
    v
[27.6 Communicating]
    |
    v
[Validation as a habit]
    |
    v
[Worked example] --> [Exercise EX079]

Learning outcomes

You will (1) deploy the security controls to all client projects; (2) validate each works; (3) record results; (4) handle projects that cannot yet comply.

27.1 Rollout plan

Controls are rolled out project by project, starting with the most sensitive clients identified in chapter 11. Each project gets the shared upload module, the pipeline template, lock-file enforcement and digest recording. Starting with Greenleaf and museum-tickets, whose data is most sensitive, means the highest-risk sites gain the controls first if the rollout is interrupted. Each project receives the same four controls, so the validation checklist can be identical across projects. The two legacy projects come last because they need separate handling.

27.2 Validation tests

For each project, Diego runs a validation checklist with synthetic data: a disallowed upload is rejected with its reason; the pipeline uses pinned actions and a read-only token; a lock-file mismatch fails the build; the deployment record holds a digest; the drift check reports the project as matching. Each item on the checklist tests exactly one of the rolled-out controls. If any item fails, the project is not marked complete until the fix is deployed and the whole checklist is run again. Using the same synthetic files for every project means a result in one project can be compared directly with another, and a failure points to the project rather than the test data.

27.3 Recording results

Results are recorded per project with date and tester, forming evidence for clients and for Brightwave's own review. Recording the tester and date makes each validation result traceable to a person. When a client asks whether their site has the new upload checks, Brightwave answers from the record rather than from memory. The results also feed the capstone presentation, where Diego shows validation records for all 23 projects as evidence that the controls exist. Records also show when each project was last validated, so later changes can trigger a fresh run.

27.4 Projects that cannot comply

Two legacy projects cannot use the new upload module without a rewrite. They get compensating steps (tighter size limits and storage rules) and a rebuild date. The compensating steps reduce exposure until the rebuild without pretending the projects comply. A tighter size limit and stricter storage rules cover the most important gaps, and the rebuild date is tracked in the monthly report. These are the same two legacy projects that held most of the remaining stale libraries and the slowest fixes.

27.5 Rollback

Each rollout can be reversed by redeploying the previous approved digest if a client site breaks. Because every deployment records its digest, the previous version is known exactly and can be redeployed through the pipeline in minutes. Rollback does not bypass the approved-image rule, since the earlier digest is already on the approved list. The one rollback during the rollout used this path, and the corrected change was redeployed the next day. Owners are told how to roll back before each project's rollout begins.

27.6 Communicating

Clients receive a short note on what changed and any visible effects, such as new upload messages. Telling clients in advance prevents surprise when an upload is now rejected with a message. Greenleaf's note mentions the new upload messages and the 5 MB limit, so reception staff can explain them to pet owners. The note is short and avoids technical detail, following the same style as the January message. Clients with no visible change still receive a brief note confirming what was updated.

Validation as a habit

The validation checklist becomes part of the release process for new projects, so each new client starts with every control in place and recorded. The checklist takes about twenty minutes per project with the synthetic test files ready.

Worked example

Rollout across 23 projects takes five weeks. Twenty-one pass every validation item on the first attempt or after small fixes, including one that first needs a rollback when an upload change rejects a file format the client really uses; the format is added to its allowed list after review and redeployed the next day. The two legacy projects are validated against their compensating steps instead.

Synthetic case. Projects and results are synthetic.

Errors and limits

Validation proves the control is present; monitoring proves it stays present.

Exercises

Synthesis

Roll out in order, validate each project and plan for exceptions.

Continue studying — chapter 27 of 30

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