Chapter 38 — Capstone implementation
Lesson map
Lesson 38 published. Map, example, EX112.
flowchart TD
N0["Learning outcomes"]
N1["38.1 Building the report"]
N2["38.2 Pipeline scan"]
N3["38.3 Testing"]
N4["38.4 Deployment"]
N5["38.5 Problems"]
N6["38.6 Documentation"]
N7["Code review"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX112"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["38.1 Building the report"]
N2["38.2 Pipeline scan"]
N3["38.3 Testing"]
N4["38.4 Deployment"]
N5["38.5 Problems"]
N6["38.6 Documentation"]
N7["Code review"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX112"]
[Learning outcomes]
|
v
[38.1 Building the report]
|
v
[38.2 Pipeline scan]
|
v
[38.3 Testing]
|
v
[38.4 Deployment]
|
v
[38.5 Problems]
|
v
[38.6 Documentation]
|
v
[Code review]
|
v
[Worked example] --> [Exercise EX112]
Learning outcomes
You will (1) build the posture report and pipeline secret scan; (2) test with synthetic data; (3) deploy with the cloud team; (4) handle problems.
38.1 Building the report
The report combines the registry, account, logging, benchmark and pod security checks into one weekly document with trends and owners. Each section links to evidence files.
Linking to evidence files lets anyone check a finding without asking Samuel. The trend line shows whether the total is falling, and the owner column shows who should act. The summary at the top lists only new and high-severity findings, which the cloud team asked for during evaluation. Each check family is a separate module.
38.2 Pipeline scan
The build pipeline scans image layers for key-like strings using pattern and entropy rules, failing the build on a match unless the string is in a reviewed placeholder allow list.
Pattern rules catch strings that look like known key formats; entropy rules catch random-looking strings that might be secrets of an unknown format. Scanning image layers, not just source code, matters because the opening case's connection string was added during the build, not committed to the repository. Matches report the layer and file, not the secret.
38.3 Testing
Synthetic exports and images with known problems confirm each check works; compliant inputs confirm no false failures.
For the scan, Samuel built a synthetic image with a fake key in one layer and confirmed the build failed, and another with only an allowed placeholder and confirmed it passed. For the report, synthetic exports with an anonymous repository and a missing logging region confirmed each finding appeared correctly. Tests run automatically on every change to the report code, as with the earlier checker. Samuel also kept one synthetic export for each check family that should produce no findings at all, which confirms that clean input yields a clean report and catches checks that report problems too eagerly.
38.4 Deployment
The report runs in the shared tooling account with read-only access to exports. The scan is added to the pipeline in warning mode for two weeks, then blocking.
The tooling account is separate from production, and the report's identity can read exports but not change anything. Warning mode let the team see what the scan would have blocked without stopping any build. The switch to blocking happened on a planned date, announced to developers a week ahead. The report's output is stored for comparison.
38.5 Problems
An export format changed mid-project, breaking the identity check; a loader update and test fixed it. Warning mode revealed three test fixtures with realistic-looking fake keys, which were replaced by obvious placeholders.
The buffer week in the plan absorbed the export format change. The realistic fake keys were a useful find: test fixtures that look exactly like real keys train people to ignore scanner warnings, and some secret scanners outside Westmere might report them. Obvious placeholders avoid both problems. Each was logged in the risk log.
38.6 Documentation
A guide explains how to read the report and how to request allow-list entries.
The guide explains what each part of the report means, how severity is assigned and what an owner should do with a finding. Allow-list requests need a reason and a reviewer's approval. Samuel tested the guide by asking a team member who had not seen the report to use it alone. Requests and decisions are kept with the allow list, so reviewers can see why each entry exists. The guide also explains what to do when the report looks wrong, such as checking the export date, so users do not lose trust after a single bad week and know whom to contact.
Code review
Tom's team reviews the report code before it runs in the tooling account, checking that it only reads exports and writes reports, and that no credentials are stored in it. The reviewer suggests separating each check into its own module with tests, which Samuel does. Review also catches that the report printed full resource identifiers that included a student project name; these are shortened to avoid exposing project details in a widely shared document.
Worked example
In its first blocking week, the scan stops a build containing a real storage access key copied from a developer's notes. The developer removes it and the key is rotated, exactly the kind of event that caused the opening case.
Synthetic case. Implementation details are synthetic.
Errors and limits
Warning modes that never end become ignored; set a date.
Exercises
- EX112 — Report sources. Which checks feed the report? Rubric: 3 = registry, account, logging, benchmark, pod security; 2 = three; 1 = one; 0 = none.
- EX113 — Warning mode. What did warning mode reveal? Rubric: 3 = realistic fake keys in fixtures; 2 = partial; 1 = vague; 0 = none.
- EX114 — First block. What did the scan block? Rubric: 3 = real key from developer's notes; 2 = partial; 1 = vague; 0 = none.
Synthesis
Build, test and roll out gradually; expect problems.
Continue studying — chapter 38 of 40
← Chapter 37 (draft) · Course chapter index · Chapter 39 (draft) →