Courses Software supply chain securityBuild integrity & SLSA

Trusted, isolated builders

A build you can actually trust the output of.

Advanced12 min · lesson 9 of 18

The build environment is code execution with access to your source, your dependencies, and often production credentials — so who and what runs the build determines whether its output can be trusted at all. A trusted builder is isolated (one build cannot see or affect another), ephemeral (a fresh environment per build, destroyed after, so nothing persists), and least-privileged (it holds only the credentials that specific build needs, ideally short-lived via OIDC rather than standing secrets).

What makes a builder trustworthy

the properties

isolated

builds cannot affect each other

ephemeral

fresh + destroyed per build

least privilege

short-lived, scoped credentials (OIDC)

provenance-generating

the builder, not the build, signs it

The key L3 idea: the build STEPS cannot influence the provenance — the trusted builder produces it, so a malicious build cannot forge its own origin.

The build cannot vouch for itself

The subtle, crucial property at higher assurance is separation between the build steps and the provenance about them. If the same untrusted build script that might be compromised also writes its own provenance, a malicious build simply lies about what it did. So a hardened builder generates the provenance itself, outside the control of the build steps — the builder attests "I ran this source, in this isolated environment," and the build cannot forge that statement. This is why "use a trusted, hosted builder" is a real security control, not just convenience.

Practical trusted builders

In practice this means: use your platform’s hosted build service rather than a self-managed builder where you can, run each job in an ephemeral isolated container/VM (never a shared, long-lived, privileged runner), authenticate to downstream systems with short-lived OIDC tokens instead of stored credentials, and adopt the reusable/hardened build workflows (like the SLSA GitHub generators) that produce non-falsifiable provenance for critical artifacts. Every one of these shrinks what a compromised build can reach and forge.

terminal

# the runner-hardening and OIDC lessons from the GitLab course are the L2/L3 substrate:
#   - ephemeral, non-root, isolated executor (container/pod per build)
#   - no privileged mode, no docker.sock mount
#   - OIDC short-lived tokens, not long-lived stored credentials
#   - a hardened/reusable workflow that signs provenance outside the build steps

A shared privileged runner is an L0 builder

All the SLSA levels and provenance in the world mean nothing if the artifact is built on a shared, privileged, long-lived runner that untrusted jobs also touch — an attacker there can compromise the build and its outputs directly. Builder isolation is the foundation the rest of the framework stands on: harden the runner first (as the GitLab course covers), then the provenance you generate is worth trusting.

Hermetic & reproducible buildsSigstore: Cosign, Fulcio & Rekor