Chapter 26 — Application and software supply chain security: methods II
Lesson map
Lesson 26 published. Map, example, EX076.
flowchart TD
N0["Learning outcomes"]
N1["26.1 Why sign"]
N2["26.2 Keyless signing"]
N3["26.3 Provenance"]
N4["26.4 CampusEats' level"]
N5["26.5 Verifying at deployment"]
N6["26.6 in-toto"]
N7["Transparency logs"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX076"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["26.1 Why sign"]
N2["26.2 Keyless signing"]
N3["26.3 Provenance"]
N4["26.4 CampusEats' level"]
N5["26.5 Verifying at deployment"]
N6["26.6 in-toto"]
N7["Transparency logs"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX076"]
[Learning outcomes]
|
v
[26.1 Why sign]
|
v
[26.2 Keyless signing]
|
v
[26.3 Provenance]
|
v
[26.4 CampusEats' level]
|
v
[26.5 Verifying at deployment]
|
v
[26.6 in-toto]
|
v
[Transparency logs]
|
v
[Worked example] --> [Exercise EX076]
Learning outcomes
You will (1) sign build artifacts and verify signatures before deployment; (2) record build provenance; (3) explain SLSA build levels; (4) integrate verification into deployment.
26.1 Why sign
A hash shows the bytes match a reference; a signature shows who produced them. CampusEats' build service signs each release bundle, and the deployment step verifies the signature before installing.
Together they answer two questions: are these the expected bytes, and did our build service produce them? Lena notes that verification happens at deployment, so a bundle altered after the build would be refused. Signatures matter most at the step between build and deployment, which is where an attacker with access to the artifact store could otherwise swap a bundle without changing any hash in the lockfile.
26.2 Keyless signing
Long-lived signing keys can leak, like the token did. Sigstore (Newman et al., 2022) issues short-lived certificates tied to the build service's identity and records signatures in a public transparency log. CampusEats adopts this approach for its release bundles.
Without a long-lived key there is nothing to steal from a developer's laptop or a configuration file. Lena checks the transparency log entry for one release and confirms it names the expected build identity. The public log also means the society could notice a signature it did not expect, such as one made by a stolen build credential.
26.3 Provenance
Provenance is a record of how an artifact was built: which source commit, which build service, which steps. SLSA v1.0 defines build levels: Level 1 requires provenance to exist; Level 2 requires a hosted build platform that signs provenance; Level 3 requires a hardened platform that resists tampering by build users.
Lena reads the provenance for one CampusEats release and confirms it names the commit and the workflow that built it. Lena explains the levels to the society with the CampusEats build as the example, since abstract definitions are harder to remember than a familiar pipeline.
26.4 CampusEats' level
Builds run on a hosted CI service that generates signed provenance, roughly matching Build Level 2. Level 3 depends on the CI provider's guarantees, which the society reviews.
Lena notes in a decision record why Level 3 is not claimed: the society cannot itself verify how isolated the CI provider's builds are. The record names what evidence would allow a higher claim, such as a provider statement describing build isolation, and sets a date to check again. Claiming only what the evidence supports keeps the release reports honest.
26.5 Verifying at deployment
The deployment step checks: the signature is valid and from the expected build identity; the provenance shows the expected repository and a reviewed commit. If any check fails, deployment stops.
Lena tests each check in the test environment by trying to deploy a bundle signed by a different identity and a bundle built from an unreviewed branch; both are refused with a clear message. A rule that has never been seen to fail cannot be trusted to work, so these tests run whenever the deployment step changes.
26.6 in-toto
in-toto (Torres-Arias et al., 2019) generalises this idea, recording and verifying every step in the chain.
Where SLSA describes the build, in-toto can describe the whole path, including tests, review and packaging, and check that each step was done by the expected party. For CampusEats, Lena judges it more than the project needs today, since the hosted CI provenance already covers the step most at risk. She records it in the society's notes as an option if the release process grows.
Transparency logs
Because signatures are recorded in a public log, the society can check that no unexpected signatures were made with its build identity. A monthly script lists log entries for CampusEats and compares them with known releases.
Worked example
Lena tests the deployment check in the test environment with a synthetic bundle signed by a personal identity rather than the build service. Deployment is refused with a clear message, as required.
Synthetic case. The signing setup is synthetic.
Errors and limits
Signatures prove origin, not quality; a signed bundle can still contain a flaw.
Exercises
- EX076 — Hash vs signature. What does a signature add to a hash? Rubric: 3 = who produced it; 2 = partial; 1 = vague; 0 = none.
- EX077 — SLSA levels. Summarise SLSA Build Levels 1–3. Rubric: 3 = L1 provenance exists; L2 hosted signed; L3 hardened tamper-resistant; 2 = two; 1 = one; 0 = none.
- EX078 — Test result. What did the deployment test show? Rubric: 3 = personal-identity bundle refused; 2 = partial; 1 = vague; 0 = none.
Synthesis
Sign releases, record provenance and verify both before deploying.
Continue studying — chapter 26 of 40
← Chapter 25 (draft) · Course chapter index · Chapter 27 (draft) →