BIPI
BIPI

SLSA L1 to L4 in Production: What Each Level Actually Costs

Cybersecurity

SLSA Level 3 is the realistic target for most enterprises in 2026. We walk through what hermetic builds, signed provenance and the GitHub Actions and Google Cloud Build paths actually look like once the auditor shows up.

By Arjun Raghavan, Security & Systems Lead, BIPI · October 19, 2024 · 8 min read

#slsa#supply-chain#build-security

SLSA framework v1.0 settled the level definitions in 2023. The question that lands on our desk in 2026 is not what SLSA L3 means, it is what L3 costs to deploy at a 200-engineer organization with 60 active build pipelines. The answer surprised the client every time.

We have walked three clients from no-formal-SLSA-posture to L3 in the last 18 months. Two on GitHub Actions, one on Google Cloud Build. Different paths, similar destinations, very different operational footprints.

Level 1: scripted build with provenance

L1 says you have a documented build process and you generate provenance attestation. Most teams hit this without realizing because their CI YAML files count as documentation and a basic SBOM generator counts as provenance. Cost: a week of policy work, no engineering changes.

L1 catches almost no real attacks. It is a baseline that lets auditors check a box. If your only goal is FedRAMP Moderate, L1 is the floor and you should aim higher anyway.

Level 2: hosted build platform with signed provenance

L2 requires a hosted build platform (you do not run builds on developer laptops) and signed provenance. GitHub Actions, GitLab CI, Cloud Build, Buildkite all qualify. Sigstore Cosign or in-toto attestations satisfy the signing requirement.

Two weeks of work for a typical mid-size org. The GitHub Actions slsa-github-generator action does most of the heavy lifting. The remaining effort is verifying the attestations on the consumption side, which often gets skipped at L2 and bites you later.

Level 3: hermetic, isolated, non-falsifiable provenance

L3 is where it gets interesting. The build must be hermetic (no network access during the build except to declared inputs), isolated (runs cannot influence each other), and the provenance must be non-falsifiable (the build platform itself signs it, not the build script).

3 months
typical SLSA L3 rollout for 60-pipeline org
12-18%
build time increase from hermetic mode
0
post-deployment supply chain incidents at L3 clients

Hermetic builds are the painful part. Your build pipeline cannot fetch from PyPI or npm at build time, you must vendor or pre-mirror dependencies. Bazel handles this beautifully. Most non-Bazel build systems handle it grudgingly. Plan for one engineer-month to convert a complex Java or Node monorepo.

GitHub Actions path to L3

Use the official slsa-github-generator workflows. They run in a separate, hardened workflow that signs the provenance using OIDC-issued ephemeral keys. The build cannot tamper with the attestation because the build does not have access to the signing key.

  • Pin all third-party actions to commit SHAs, not version tags.
  • Use OIDC for cloud authentication, never long-lived secrets.
  • Run builds with restricted GITHUB_TOKEN permissions.
  • Verify provenance at consumption time using slsa-verifier or Cosign policy controllers.

Google Cloud Build path to L3

Cloud Build emits provenance as part of Binary Authorization workflows. The hermetic story is cleaner because Cloud Build can run in private worker pools with no internet egress except to your Artifact Registry. Verification happens at admission control via Binary Authorization policies.

If you are already a heavy GCP customer, this is the lower-effort path. If you are multi-cloud or GitHub-centric, the GitHub Actions path is more portable.

Level 4: two-person review, parameterless builds

L4 requires two-person review of all changes that affect the build, parameterless builds (no inputs that could change the output other than the source), and full reproducibility. We have not deployed L4 outside of a security-research client and we generally do not recommend it. The marginal security gain over a well-implemented L3 is small. The operational tax is large.

Where most clients land: L3 on the production-bound build pipelines (the ones that ship binaries to customers or cloud), L2 on internal tooling, L1 documented for everything else. That triage is defensible to auditors and tractable to engineering. Trying to push everything to L3 at once is how SLSA projects die.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.