Chapter 31 — Application and software supply chain security: implementation II
Lesson map
Lesson 31 published. Map, example, EX091.
flowchart TD
N0["Learning outcomes"]
N1["31.1 Provenance in CI"]
N2["31.2 Signing"]
N3["31.3 Storage"]
N4["31.4 Deployment verification"]
N5["31.5 End-to-end test"]
N6["31.6 Performance"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX091"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["31.1 Provenance in CI"]
N2["31.2 Signing"]
N3["31.3 Storage"]
N4["31.4 Deployment verification"]
N5["31.5 End-to-end test"]
N6["31.6 Performance"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX091"]
[Learning outcomes]
|
v
[31.1 Provenance in CI]
|
v
[31.2 Signing]
|
v
[31.3 Storage]
|
v
[31.4 Deployment verification]
|
v
[31.5 End-to-end test]
|
v
[31.6 Performance]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX091]
Learning outcomes
You will (1) implement build provenance and signing in CI; (2) implement deployment verification; (3) integrate SBOM storage with artifacts; (4) test the full path end to end.
31.1 Provenance in CI
The hosted CI platform generates provenance for each build: builder identity, source repository, commit digest, build steps and output digests. The record is signed by the platform, so a compromised build script cannot forge it, which is the key property of SLSA v1.0's higher build levels.
Because the platform, not the build steps, writes the record, an attacker who changes the build script still cannot make the provenance claim a different source or builder. Deployment then checks those claims against policy before anything is installed.
31.2 Signing
The artifact is signed with keyless signing tied to the CI workflow's identity, and the signature is recorded in a transparency log, following the Sigstore model (Newman et al., 2022). Anyone can later check when and by which identity the artifact was signed.
The transparency log is public and append-only, so a signature made with Coastline's identity at an unexpected time, or for an unknown artifact, would be visible. Coastline monitors the log for its own identity and alerts on entries that do not match a CI run. No long-lived key exists to steal.
31.3 Storage
The artifact, its SBOM, provenance and signature are stored together and linked by the artifact digest. Retention is at least as long as the release is in use, plus one year.
Keeping the records together means one lookup by digest returns everything needed to verify or investigate a release. If records were stored separately, one might be deleted or overwritten while the others remain, leaving a release that cannot be checked. The extra year after a release leaves use covers investigations that start late, such as when a compromised component is discovered months after it shipped. Storage is write-once, so records cannot be altered after they are saved.
31.4 Deployment verification
The deployment tool fetches the artifact and its records, verifies the signature, checks the provenance against policy (chapter 38's lab) and compares digests before installing. Any failure stops the deployment with a clear message.
The order of checks matters little for security, since all must pass, but checking the signature first gives the clearest error for the commonest failure. The clear message names which check failed and for which artifact, so the person deploying can tell a configuration mistake from a possible tampering case and escalate the second at once.
31.5 End-to-end test
A staging pipeline deploys a known-good synthetic artifact and three deliberately flawed ones (wrong digest, wrong builder, missing signature). The test passes only if the first deploys and the others are refused.
Each flawed artifact tests one check in isolation, so a failure points to the broken part. Testing only the good case would prove nothing about the checks, since a tool that verifies nothing also deploys a good artifact. The test runs after every change to the deployment tool, its configuration or the policy, and weekly otherwise, because the worked example shows how a single flag can quietly disable a check.
31.6 Performance
Verification adds 12 seconds to deployment, acceptable for the team.
Twelve seconds is small next to the minutes a deployment already takes, and far less than the cost of investigating a tampered release. Measuring it matters anyway, because slow controls invite shortcuts: if verification took ten minutes, people would look for ways around it during urgent fixes. The team records the time for each deployment and investigates if it grows, since a sudden rise might signal a problem with the log service or cached verification material. Most of the time is spent fetching records, not checking signatures.
Worked example
During the end-to-end test, the missing-signature case deploys successfully: a configuration flag left verification in "warn" mode. The flag is changed to "enforce", the test re-run, and a CI check added that fails if the flag is ever set to warn in production configuration.
Synthetic case. Pipeline and tests are synthetic.
Errors and limits
Verification proves origin and integrity, not that the source code itself is free of flaws.
Exercises
- EX091 — Provenance contents. What does provenance record? Rubric: 3 = builder, repo, commit, steps, output digests; 2 = four; 1 = two; 0 = none.
- EX092 — Platform signing. Why must the platform sign provenance? Rubric: 3 = build script cannot forge it; 2 = partial; 1 = vague; 0 = none.
- EX093 — Warn mode. What did the end-to-end test catch? Rubric: 3 = verification in warn mode; set enforce; CI check; 2 = partial; 1 = vague; 0 = none.
Synthesis
Generate, store and verify provenance and signatures end to end, and test that failures are refused.
Continue studying — chapter 31 of 50
← Chapter 30 (draft) · Course chapter index · Chapter 32 (draft) →