Secure CI/CD Pipelines in 2026: Supply-Chain Security with Sigstore, SLSA, and Provenance Attestation

AT A GLANCE

Piece	What it is	What it answers
Sigstore (Cosign, Fulcio, Rekor)	Open source keyless signing infrastructure for software artifacts, under OpenSSF/Linux Foundation	“Who signed this, and can I verify it without managing long-lived keys?”
SLSA (Supply-chain Levels for Software Artifacts)	A framework of build-track levels (0–3) defining how trustworthy a build’s provenance is	“How tamper-resistant was the process that produced this artifact?”
Provenance attestation	A signed, structured statement (in-toto format) describing how/where/from-what an artifact was built	“What’s the verifiable, machine-readable evidence behind the SLSA claim?”

Short Verdict

Sigstore and SLSA solve two different, complementary problems, and most teams need both, not one or the other. Sigstore answers “who signed this artifact,” using short-lived, identity-bound certificates instead of long-lived private keys you have to protect and rotate forever. SLSA answers a bigger question — “how trustworthy was the build process itself” — by defining escalating levels of build-platform hardening, with signed provenance as the evidence that ties a specific artifact to a specific, auditable build. Neither is a product you buy; both are specs and open tooling you adopt incrementally, and GitHub Actions now ships native support for generating the attestations that back both.

What Sigstore Actually Does

Sigstore’s own documentation frames the problem plainly: unsigned software is exposed to typosquatting, compromised distribution sites, and post-publication tampering, while traditional key-based signing has its own failure modes — proving identity, protecting and distributing keys, and recovering trust after a key leaks. Sigstore’s answer is to replace long-lived private keys with short-lived, identity-bound ones, via three components:

• Cosign — the client that signs and verifies artifacts (binaries, container images, SBOMs).
• Fulcio — a code-signing certificate authority that checks an OpenID Connect (OIDC) identity token (a CI workflow’s identity, a service account, or a user’s email) and, if valid, issues a short-lived certificate binding that identity to an ephemeral public key.
• Rekor — a tamper-resistant, append-only transparency log that records every signing event’s digest, signature, and certificate, so signatures are publicly auditable after the fact.

The “keyless” part works like this: the client generates a throwaway key pair, sends a certificate signing request to Fulcio along with its OIDC token, Fulcio verifies the token and issues a short-lived cert, the private key is discarded immediately after signing, and the event lands in Rekor’s log. Verification checks the signature, confirms the certificate’s identity matches what’s expected (e.g. “this was signed by this exact GitHub Actions workflow”), validates the cert chain against Sigstore’s root of trust, and confirms the matching Rekor log entry exists. Nobody — not even the signer — has a long-lived private key to lose or leak.

What SLSA Actually Defines

SLSA’s Build track defines four levels of build-process trustworthiness, each one a strict superset of the last:

Level	Requirement	What it guards against
Build L0	No requirements — the absence of SLSA	Nothing; baseline for dev/test builds
Build L1	Consistent build process; generates provenance describing the build platform, process, and top-level inputs	Accidental mistakes — provenance may be unsigned and is easy to forge or bypass
Build L2	Everything in L1, plus builds run on dedicated hosted infrastructure, with signed provenance tied to that platform	Tampering after the build — consumers can validate provenance authenticity
Build L3	Everything in L2, plus the platform isolates runs from each other and keeps signing secrets away from user-defined build steps	Tampering during the build, including by other jobs on the same platform

Provenance itself — the artifact that ties each level together — is formally defined in the SLSA/in-toto attestation model as a signed, machine-readable statement with three parts: an envelope (the signature and signer identity, typically in DSSE format), a statement (which binds the attestation to a specific subject — the artifact’s hash — plus a predicate type), and a predicate (the actual metadata, such as the build command and dependencies used). The point of structuring it this way, rather than just signing the artifact directly, is that the metadata is explicit and machine-readable — a policy engine can check not just “is this signed” but “was this built from the expected source repo, by the expected CI system, using the expected command.”

Putting It Together in a Real Pipeline

GitHub Actions has native support for generating these attestations without standing up Fulcio or Rekor yourself — GitHub operates its own Sigstore-backed signing path behind the action. Per GitHub’s own documentation, available on all current plans (public repos on Free/Pro/Team; private repos need GitHub Enterprise Cloud), the workflow is:

1. Grant the workflow id-token: write, contents: read, and attestations: write permissions (packages: write too, for container images).
2. After the build step, add a step using GitHub’s attestation action, pointing it at the built artifact.
3. For binaries, set the artifact’s path; for container images, set the fully-qualified image name and its sha256: digest and push to the registry; for SBOMs, add the SBOM path as a separate predicate.

permissions:
  id-token: write
  contents: read
  attestations: write

steps:
  - uses: actions/checkout@v4

  - name: Build artifact
    run: ./build.sh

  - name: Attest build provenance
    uses: actions/attest@v4
    with:
      subject-path: "dist/myapp-linux-amd64"

Verification happens with the GitHub CLI: gh attestation verify <artifact-path> -R <org>/<repo> for binaries, or the same command prefixed with oci:// against a logged-in registry for container images. That single command checks the signature, the signer identity, and the Rekor-equivalent log entry in one step — the same verification chain Sigstore defines generally, wired into GitHub’s CI identity.

Trade-offs

• Pros of adopting Sigstore/SLSA: no long-lived signing keys to protect, rotate, or leak; publicly auditable transparency log means a compromised identity leaves a trace; incremental adoption — SLSA L1 (just generate provenance) is low-effort and still gives you an audit trail; GitHub’s native integration means no separate signing infrastructure to run for the common case.
• Cons / real costs: SLSA L3 requires genuine build-platform isolation, which is a real engineering investment, not a config flag; verifying attestations downstream requires policy tooling (admission controllers, deployment gates) that many teams haven’t built yet, so signed provenance sitting unused provides no protection; OIDC-based keyless signing shifts trust to your CI identity provider’s security, which becomes a new high-value target; private-repo attestation support requires GitHub Enterprise Cloud, which is a real constraint for teams on lower tiers.

Who Should Adopt This Now vs. Who Can Wait

Adopt now if you publish artifacts that other teams or the public consume — open source libraries, container base images, CLI binaries — where an unsigned or unverifiable artifact is a direct supply-chain risk to everyone downstream; if you’re already using GitHub Actions, generating SLSA L1/L2 provenance is a small, low-risk addition. It’s also worth prioritizing if you’re subject to regulatory pressure around software supply-chain integrity (e.g. government or critical-infrastructure vendors), where provenance attestation is increasingly an explicit requirement rather than a nice-to-have. It can reasonably wait if your build output never leaves a single trusted, access-controlled internal environment and you don’t yet have any downstream policy engine that would consume the attestations — in that case, invest first in the verification/enforcement side (so signed provenance actually gates deployment) before spending more effort generating attestations nobody checks.

Bottom Line

Sigstore removes the key-management excuse for not signing artifacts; SLSA gives you a shared vocabulary and a staged path for how much you trust the process that produced them; provenance attestation is the concrete, verifiable artifact that connects the two. None of this is exotic anymore — it’s a few workflow permissions and one action step in GitHub Actions to get real, auditable evidence of what built your software and from what. The harder, still-unsolved part for most teams is the back half: actually verifying and enforcing those attestations at deploy time, not just generating them.

FAQ

Do I need to run my own Fulcio/Rekor instance? No — the public Sigstore infrastructure is free to use for open source projects, and GitHub Actions’ native attestation feature uses GitHub’s own Sigstore-backed signing path, so most teams never operate Fulcio or Rekor themselves.

Is SLSA a certification I can get audited for? No — SLSA is a specification describing levels of build-process guarantees, not a certifying body. You self-assess or build tooling (like the Generic SLSA Verifier) to check a given artifact’s provenance against a level’s requirements.

What’s the difference between signing an artifact and attesting to it? A plain signature only proves who signed something; an attestation is a structured, signed statement that makes the claim explicit (e.g. “built from commit X using command Y”), which is what lets automated policy engines make decisions rather than just confirming authenticity.

Does this replace secrets management or policy-as-code tooling? No — supply-chain signing/provenance, secrets management, and policy-as-code/CSPM are three distinct, complementary layers of a secure pipeline. See the related posts below for the other two.

Sources

• Sigstore Documentation: Overview
• sigstore.dev
• SLSA Specification v1.0: Build Track Levels
• SLSA: Attestation Model
• GitHub Docs: Using Artifact Attestations to Establish Provenance for Builds

Related reading on this site: Policy-as-Code and Cloud Security Posture Management in 2026 and Secrets Management for Cloud-Native Pipelines in 2026.