Chapter 18 — Application and software supply chain security: controls
Lesson map
Lesson 18 published. Map, example, EX052.
flowchart TD
N0["Learning outcomes"]
N1["18.1 Recording digests"]
N2["18.2 Provenance"]
N3["18.3 Approved images"]
N4["18.4 Brightwave's target"]
N5["18.5 Exceptions"]
N6["18.6 Evidence"]
N7["Checking the records"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX052"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["18.1 Recording digests"]
N2["18.2 Provenance"]
N3["18.3 Approved images"]
N4["18.4 Brightwave's target"]
N5["18.5 Exceptions"]
N6["18.6 Evidence"]
N7["Checking the records"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX052"]
[Learning outcomes]
|
v
[18.1 Recording digests]
|
v
[18.2 Provenance]
|
v
[18.3 Approved images]
|
v
[18.4 Brightwave's target]
|
v
[18.5 Exceptions]
|
v
[18.6 Evidence]
|
v
[Checking the records]
|
v
[Worked example] --> [Exercise EX052]
Learning outcomes
You will (1) record image digests for every deployment; (2) record build provenance; (3) deploy only approved images; (4) describe SLSA build levels.
18.1 Recording digests
Each built image has a digest, a fingerprint of its contents. The deployment record stores the digest, the commit and the build run, so Brightwave can always say exactly what is running. The digest changes if even one byte of the image changes, so it identifies contents exactly. A tag such as a version name can be moved to a different image. Knowing exactly what is running makes the drift check and the monthly tracing possible. Diego's monthly tracing relies on these three fields being present for every deployment.
18.2 Provenance
Provenance is a signed statement of how an artifact was built: source, builder and steps. SLSA v1.0 defines build levels: L1 provenance exists, L2 a hosted build service signs it, L3 builds are hardened against tampering between runs. in-toto (Torres-Arias et al., 2019) and Sigstore (Newman et al., 2022) provide ways to create and verify such statements. Brightwave records the source commit, the build service and the build steps for each image. Provenance answers how an artifact was produced; it does not say whether the code inside is free of flaws.
18.3 Approved images
Hosting accepts only images whose digests appear in the approved list produced by the main-branch build. This rule is what refuses the locally built test image a developer tries to deploy. It also prevents a repeat of the museum-tickets weekend hotfix, which was built and deployed by hand before the rule existed. The approved list is produced automatically by the main-branch build, so no person edits it by hand. A digest not on the list is refused even if the image came from a trusted developer's laptop. That refusal is the expected outcome, and the developer rebuilds through the pipeline instead.
18.4 Brightwave's target
The agency targets SLSA build L2 for all client projects this year. Brightwave already uses a hosted build service and records digests, so the remaining work is to have that service produce signed provenance for every client project. L3, with builds hardened against tampering between runs, is left for after the placement. Reaching L2 for every client project would mean each deployment's provenance is signed by the hosted build service. Brightwave tracks progress in the monthly report, project by project, so laggards are visible.
18.5 Exceptions
Emergency changes still go through the build; there are no manual uploads to hosting. During an outage the pipeline may run with a shortened review, but the image is still built by the build service and recorded by digest. The museum-tickets weekend hotfix shows why: a manual upload left a build nobody could trace. After the emergency, the team reviews the change normally, so the shortened review is never the final one. Because nothing reaches hosting except through the build, the drift check and the approved list stay accurate even in an outage.
18.6 Evidence
Digest records give clients evidence of what changed and when. When a client asks what changed on their site last month, Brightwave can list each deployment with its date, commit and digest. The same records supported the monthly tracing checks that found one project recording tags instead of digests. Clients ask such questions after incidents or during their own audits. Brightwave can answer from the deployment records in minutes, without relying on anyone's memory. The records also show each change's commit, so a client can be told what the change was meant to do.
Checking the records
Each month Diego picks three deployments at random and traces each from the running digest back through the registry to the build run and commit. If any link is missing, the gap is fixed in the pipeline. The first check finds one project whose deployment step recorded the image tag but not the digest; because tags can be moved to point at a different image, only the digest identifies the contents reliably. The step is corrected to record digests, and a test is added to the shared pipeline template.
Worked example
After the approved-image rule is introduced, a developer's attempt to deploy a locally built test image to a client's production is refused. The developer rebuilds through the pipeline, and the event confirms the control works.
Synthetic case. Builds and events are synthetic.
Errors and limits
Provenance proves how something was built, not that the code is safe.
Exercises
- EX052 — Digest record. What does the deployment record store? Rubric: 3 = digest, commit, build run; 2 = two; 1 = one; 0 = none.
- EX053 — SLSA L2. What does SLSA build L2 add over L1? Rubric: 3 = hosted build service signs provenance; 2 = partial; 1 = vague; 0 = none.
- EX054 — Refused deploy. What did the refused deploy show? Rubric: 3 = control works; local images blocked; 2 = partial; 1 = vague; 0 = none.
Synthesis
Record what runs and deploy only what the pipeline built.
Continue studying — chapter 18 of 30
← Chapter 17 (draft) · Course chapter index · Chapter 19 (draft) →