A Practical Guide to Meeting SLSA Level 3 in Regulated Industries
Meeting SLSA Level 3 in a regulated industry means producing tamper-resistant builds with signed, verifiable provenance for every artifact you ship — including the transitive open-source and legacy dependencies inside it. In practice, that demands a hardened build platform, non-falsifiable attestations, a documented chain of custody from source to release, and a remediation path for vulnerable components you cannot simply upgrade away. For banks, insurers, and other regulated software producers operating under PCI DSS 4.0, DORA, and NYDFS scrutiny, the binding constraint is rarely the build system itself; it is the long tail of End-of-Life (EOL) libraries and pinned versions that auditors, customers, and frameworks like SLSA all expect you to keep patched.
SLSA — Supply-chain Levels for Software Artifacts — is the OpenSSF framework that grades build integrity from Level 1 (basic provenance) to Level 4 (hermetic, two-party-reviewed builds). Level 3 is the practical bar most regulated buyers now require: a hardened build service, signed provenance, and source/build platform isolation that resists insider tampering. This guide walks through what Level 3 actually requires, where regulated teams typically stall, and how to close the dependency-remediation gap without forcing the risky upgrades that break production systems.
What does SLSA Level 3 require in regulated industries?
SLSA Level 3 requires that every build of your software be produced by a hardened, tamper-resistant build platform that emits signed, verifiable provenance — and in regulated industries, those requirements collide with the realities of legacy systems, end-of-life dependencies, and compliance regimes like PCI DSS 4.0, DORA, and FedRAMP. SLSA (Supply-chain Levels for Software Artifacts) is an OpenSSF framework that grades build integrity from L1 to L4; Level 3 is the threshold most regulated buyers now treat as the credible bar for production software.
Which attributes define Level 3 compliance?
The Level 3 specification narrows what "trustworthy build" actually means. The attributes you must satisfy:
| Attribute | Required value at L3 | Why it matters in regulated sectors |
|---|---|---|
| Source integrity | Version-controlled, retained, two-party reviewed | Auditable change history for PCI DSS 4.0 and SOX |
| Build platform | Hosted, hardened, isolated per build | Prevents tenant-to-tenant tampering in shared CI |
| Provenance | Generated by the build system, signed, non-falsifiable | Required evidence for DORA ICT risk reporting |
| Provenance contents | Identifies source, build steps, and all dependencies | Maps to SBOM expectations (SPDX, CycloneDX) |
| Isolation | Builds cannot influence each other or the provenance | Closes the SolarWinds-style attack class |
| Common requirements | Documented, reviewed, two-person controlled | Aligns with separation-of-duties controls examiners expect |
How do regulated sectors extend the baseline?
Finance, healthcare, and government layer additional duties on top of the raw SLSA text. A bank under NYDFS Part 500 must tie provenance to named approvers; a HIPAA-covered entity must retain build records alongside PHI access logs; a FedRAMP Moderate workload must demonstrate that third-party and transitive open-source components carry equivalent assurance. That last point is where most programs stall: SLSA assumes you can rebuild components from controlled source, but a CentOS 7 package, an EOL Java library, or a deeply nested transitive dependency rarely cooperates.
An underappreciated specification detail is provenance for dependencies you did not build. Level 3 does not require you to upgrade them — it requires you to attest to what is in them and how they were fixed. That distinction is what makes back-ported security fixes a viable Level 3 strategy rather than a workaround.
How does SLSA Level 3 differ from Levels 1, 2, and 4?
SLSA Levels differ along three axes that matter to regulated buyers: how trustworthy the build process is, how completely provenance is generated and signed, and how strongly the build environment is isolated from tampering. Level 3, the focus of most financial-services and critical-infrastructure programs today, is where SLSA (Supply-chain Levels for Software Artifacts, the OpenSSF framework for build integrity) crosses from "documented" to "hardened."
Which criteria should you weight when comparing the levels?
Before reading the table, anchor on the criteria that auditors actually test. Build integrity asks whether builds are scripted, reproducible, and free of ad-hoc developer intervention. Provenance asks whether every artifact ships with signed, machine-verifiable metadata describing how it was built. Isolation asks whether the build platform itself can be compromised by the code it builds, by tenants sharing the runner, or by insider access. For regulated industries, isolation usually carries the heaviest weight, because it is the control DORA and PCI DSS 4.0 examiners can most directly map to their own tamper-evidence requirements.
How do the four levels compare side by side?
| Criterion | Level 1 | Level 2 | Level 3 | Level 4 |
|---|---|---|---|---|
| Build integrity | Scripted build | Version-controlled, hosted build service | Hardened build platform, no user-injectable steps | Two-party review, hermetic + reproducible builds |
| Provenance | Generated, may be incomplete | Authenticated and service-generated | Non-falsifiable, signed by the platform | Same as L3, plus dependency completeness |
| Isolation | None required | Build runs on a hosted service | Strong tenant and source isolation; ephemeral runners | Hermetic builds with no network egress |
| Typical regulated use | Internal tooling | Lower-risk services | Production systems under DORA, PCI DSS 4.0, NYDFS | Highest-assurance workloads (rare) |
The practical verdict: Level 2 is mostly an evidence exercise, Level 3 is where build platforms must be re-architected, and Level 4 remains aspirational for most enterprise estates with legacy or EOL components. Level 3 is the realistic compliance bar — and the one where un-upgradeable dependencies most often block sign-off.
Why is SLSA Level 3 critical for compliance with regulations like FedRAMP, HIPAA, and DORA?
SLSA Level 3 has become critical for regulated builders because frameworks like FedRAMP, HIPAA, and DORA increasingly treat the software supply chain itself as in-scope — not just the deployed application. SLSA (Supply-chain Levels for Software Artifacts), a build-integrity framework stewarded by the OpenSSF, defines Level 3 as the tier where builds run on hardened, tamper-resistant infrastructure and emit signed, non-falsifiable provenance for every artifact.
When you operate under FedRAMP, HIPAA, or DORA, how does Level 3 map to your obligations?
If you are a financial institution preparing for DORA's ICT third-party risk articles, a healthcare platform under HIPAA's Security Rule, or a cloud provider on a FedRAMP authorization path, SLSA Level 3 directly answers control families that other evidence cannot satisfy on its own:
- FedRAMP (Rev. 5): SI-7 software/firmware integrity and SR-4 supply chain provenance both expect verifiable build attestations — exactly what Level 3 provenance produces.
- HIPAA Security Rule: §164.308(a)(1) risk analysis and §164.312(c) integrity controls extend to the libraries handling ePHI; signed provenance proves what code actually shipped.
- DORA: Articles 28–30 on ICT third-party risk require demonstrable assurance over software components, including open-source dependencies pulled transitively into trading and core banking systems.
- PCI DSS 4.0: Requirement 6.3.2 explicitly calls out inventorying and managing bespoke and third-party software components.
What trust signals should you collect as evidence?
Auditors do not accept "we use a secure pipeline" as a statement. They expect artifacts. A defensible Level 3 evidence pack typically includes signed in-toto attestations, an SBOM in SPDX or CycloneDX format per release, hermetic build logs, and a remediation record showing how disclosed CVEs were closed on the running version.
That last point is where regulated teams stumble. Provenance proves what you built; it does not fix a vulnerable transitive dependency in an EOL runtime. SLSA Level 3 and continuous remediation are complementary controls — provenance gives auditors integrity evidence, while back-ported fixes give them the closure evidence that turns a finding into a resolved risk.
Which build platforms and tools support SLSA Level 3 attestation?
The build platforms and tools that can produce SLSA Level 3 attestation are a narrow set: they must run builds on hardened, ephemeral, isolated infrastructure and emit signed, non-falsifiable provenance describing exactly how the artifact was produced. Most general-purpose CI runners do not qualify out of the box — the platform itself has to guarantee that build steps cannot tamper with the provenance generator.
Below is a focused survey of the platforms most regulated engineering organizations evaluate, with the attributes that matter for SLSA 3 conformance.
Which attributes determine SLSA 3 eligibility?
- Isolated, ephemeral build environment: each build runs in a fresh, non-reusable VM or container so one job cannot influence another.
- Non-falsifiable provenance: the signer of the attestation is the platform, not user-controlled build steps — keys live outside the build environment.
- Signed provenance format: typically in-toto attestations wrapped in DSSE, signed via Sigstore (cosign / Fulcio / Rekor) or an equivalent KMS-backed signer.
- Source and parameter integrity: the provenance records the exact source revision, builder identity, and build parameters, with no post-hoc edits.
- Hosted/managed builder: a trusted builder image (e.g. SLSA GitHub Generator) executes the build steps in a controlled wrapper.
Which platforms qualify today?
| Platform | SLSA 3 path | Provenance format | Signing |
|---|---|---|---|
| GitHub Actions + SLSA GitHub Generator | Reusable workflows from slsa-framework/slsa-github-generator |
in-toto v1.0 / DSSE | Sigstore (keyless OIDC) |
| Tekton Chains on Tekton Pipelines | Chains observes TaskRuns and signs results | in-toto / SPDX / CycloneDX | cosign, KMS, or x509 |
| Google Cloud Build | Built-in SLSA L3 provenance for supported builds | in-toto v0.2/v1.0 | Google-managed keys |
| GitLab CI (with SLSA components) | Hosted SaaS runners + provenance generator | in-toto / DSSE | Sigstore or GitLab signer |
How do you choose for a regulated stack?
The right question is not "which platform is most SLSA-pure" but "which platform our auditors will accept without bespoke evidence." Teams already standardized on GitHub Cloud get to L3 fastest via the reusable generator; Kubernetes-native shops lean on Tekton Chains; GCP-resident workloads default to Cloud Build. Self-hosted runners almost always break the isolation requirement — treat that as the first gate.
How do you implement hermetic and isolated builds for SLSA Level 3?
To implement hermetic, isolated builds at SLSA Level 3, you need a pipeline where every build runs in a clean, network-restricted environment with all inputs declared up front and no side channels to mutate them. Hermetic means the build cannot reach out to fetch undeclared dependencies; isolated means one build cannot influence another, and no human can tamper mid-flight. If your build can pull latest from a public registry at compile time, you do not yet meet the bar.
This requirement follows directly from SLSA 3's provenance guarantee: if you cannot prove every input, you cannot honestly attest the output. It follows that hermeticity is not a nice-to-have — it is the precondition for trustworthy provenance.
What are the concrete steps?
- Pin every input by digest. Convert floating tags (
node:20,ubuntu:latest) to immutable SHA-256 digests in your Dockerfiles, lockfiles, and base-image references. Generate an SBOM in SPDX or CycloneDX format as a build artifact. - Pre-fetch dependencies into a controlled mirror. Mirror Maven Central, npm, PyPI, and OS package repos into an internal proxy (Artifactory, Nexus, or a cloud equivalent). Builds resolve only against the mirror.
- Run builds in ephemeral, network-restricted runners. Use GitHub Actions hosted runners with egress policies, Google Cloud Build, AWS CodeBuild in a locked-down VPC, or
tekton-chainson Kubernetes with network policies denying egress except to the mirror. - Generate signed provenance. Emit SLSA provenance via
slsa-github-generator, Sigstorecosign, or an in-toto attestation. Store the attestation alongside the artifact in an OCI registry. - Verify on deploy. Gate production with a policy engine — Kyverno, OPA/Conftest, or Sigstore
policy-controller— that refuses any artifact without a valid SLSA 3 attestation.
Where do regulated teams stumble?
A common decision-stage trap is treating hermeticity as a greenfield problem. Most regulated estates contain legacy services on EOL runtimes — older RHEL, CentOS, Java 8 — where the "clean" upgrade path is precisely what created the backlog. Forcing a hermetic rebuild on those services often means forcing a risky version upgrade you have deliberately avoided.
A more pragmatic decision-stage move is to separate build integrity (hermeticity, provenance) from vulnerability remediation (the CVE backlog inside those pinned dependencies). Back-porting fixes onto the exact pinned versions lets you keep your hermetic build reproducible while still closing CVEs — no version churn, same digest discipline.
Frequently Asked Questions
What is SLSA Level 3, in plain terms?
SLSA (Supply-chain Levels for Software Artifacts) Level 3 is a tier of the OpenSSF supply-chain framework that requires a hardened, source-controlled build platform producing non-falsifiable provenance for every artifact. In practice, it means your build system is isolated, your build steps are scripted and version-controlled, and the resulting attestation cryptographically links the artifact back to its source and builder identity.
How does SLSA Level 3 differ from Levels 1, 2, and 4?
Level 1 only requires that you generate build provenance at all. Level 2 adds a hosted, authenticated build service and signed provenance. Level 3 raises the bar by requiring a hardened, tamper-resistant build platform and non-forgeable provenance. Level 4 (now folded into the broader spec) layered on two-person review and hermetic, reproducible builds — most regulated enterprises target Level 3 first because it is the highest tier achievable without rearchitecting development workflow.
Does SLSA Level 3 require me to fix every CVE in my dependencies?
No. SLSA governs how an artifact is built, not the vulnerability state of its inputs. That said, auditors under PCI DSS 4.0, DORA, and NYDFS increasingly read SLSA attestations alongside SBOM data, and a clean provenance record over a vulnerable dependency tree looks worse than one with documented remediation. Pair SLSA with a remediation workflow — including back-porting (applying a security fix to the version you already run, rather than upgrading) for transitive and end-of-life components your scanner flags as "no fix available."
Can I reach SLSA Level 3 if I run end-of-life (EOL) operating systems or libraries?
Yes, but with caveats. SLSA Level 3 cares about the integrity of your build, not the maintenance status of your inputs. You can produce conformant provenance for an artifact built on RHEL 7 or against an unmaintained Java library. The harder problem is the vulnerability ledger attached to that artifact — which is where back-ported fixes for EOL components become the practical path to keeping the system both compliant and patched without a forced rewrite.
How do SBOMs (SPDX or CycloneDX) fit alongside SLSA attestations?
An SBOM lists what is inside your artifact; a SLSA attestation proves how that artifact was built. Regulators increasingly expect both: the SBOM (in SPDX or CycloneDX format) for component transparency, and the SLSA provenance for build integrity. Generate them in the same pipeline step so the SBOM hash is included in the signed attestation — that linkage is what auditors typically look for.
Who owns SLSA Level 3 compliance — AppSec, DevSecOps, or platform engineering?
It is a shared mandate that tends to fail when any one team owns it alone. Platform engineering owns the hardened build infrastructure, DevSecOps owns the attestation and policy enforcement at deploy time, and application security owns the vulnerability posture of what gets built. A practical pattern is to name a single accountable lead — typically inside DevSecOps or product security — with explicit RACI across the other two functions.
Last updated: 2026-06-22