Before diving into certificates and transparency logs, it helps to pin down exactly what is being created and why GitHub built this as a first-class feature.

Provenance, in plain terms

An artifact attestation is a small, signed document that records the provenance of a build artifact — a binary, a container image, a package, or any file produced by a build process. “Provenance” simply means origin: which repository, which commit, which workflow, and which build steps produced this exact file. The attestation binds all of that metadata to a cryptographic hash (a digest) of the artifact itself, so that if even a single byte of the artifact changes, the attestation no longer matches it.

What it is not

This distinction matters enough that GitHub states it explicitly in its own documentation: an attestation is not a guarantee that the artifact is safe, bug-free, or free of vulnerabilities. It says nothing about code quality. What it does is remove any ambiguity about where the artifact came from, which is the foundation every other security check — vulnerability scanning, license review, code audit — depends on. You cannot meaningfully trust the results of a security scan on a binary if you are not first certain the binary is the one your source code actually produced.

This feature exists because of a specific, well-documented category of real-world attack: the software supply chain compromise.

The supply chain problem

Modern software is assembled, not written from scratch. A typical application pulls in dozens or hundreds of open-source dependencies, each built somewhere else, by someone else, on infrastructure the final consumer never sees. If an attacker compromises any single link in that chain — a build server, a maintainer’s account, a package registry — they can slip malicious code into an artifact that looks, on the surface, completely legitimate. Several major real-world incidents in the last decade followed exactly this pattern: the compromise happened not in the source code repository itself, but somewhere in the gap between source code and the final published artifact.

Closing the gap between source and binary

Artifact attestations close precisely that gap. Instead of asking consumers to trust a download link, a registry, or a build server’s reputation, attestations let them cryptographically verify that the artifact in front of them matches a specific, publicly inspectable build process, tied to a specific commit in a specific repository.

GitHub does not implement signing and verification from scratch. It builds on top of Sigstore, an open-source project purpose-built for exactly this problem, and adds three moving parts of its own on top.

flowchart LR
    A[Workflow builds artifact] --> B[Compute SHA-256 digest]
    B --> C[Request OIDC identity token]
    C --> D[Fulcio issues short-lived certificate]
    D --> E[Sign in-toto/SLSA statement]
    E --> F[Bundle: statement + certificate + signature]
    F --> G[Record event in Rekor transparency log]
    F --> H[Store attestation with GitHub]
        

Why “keyless” is the headline feature

Traditional code signing requires an organization to generate a private key, store it somewhere safe, restrict who can use it, and rotate it periodically — all famously difficult to do correctly at scale. Sigstore’s keyless signing model removes that entire burden: a brand-new key pair is generated fresh for every single signing event, used once, and then discarded within minutes. There is no long-lived secret to leak, steal, or forget to rotate.

You may likeWhat Is Git LFS (Large File Storage)?→

Following one artifact through the full signing sequence makes the earlier architecture concrete.

sequenceDiagram
    participant WF as Workflow / Runner
    participant OIDC as GitHub OIDC Provider
    participant Fulcio as Sigstore Fulcio
    participant Rekor as Sigstore Rekor Log
    participant GH as GitHub Attestation Store
    WF->>OIDC: Request identity token
    OIDC-->>WF: Short-lived OIDC token
    WF->>WF: Generate ephemeral key pair
    WF->>Fulcio: Public key + OIDC token
    Fulcio-->>WF: Short-lived signing certificate
    WF->>WF: Sign in-toto/SLSA statement
    WF->>Rekor: Record signature event
    WF->>GH: Store attestation bundle
        

Not every repository gets exactly the same Sigstore setup, and the difference matters for anyone deciding how much external transparency they are comfortable with.

This split exists for an obvious reason: a public transparency log is a feature for open-source projects, where anyone in the world benefiting from public verifiability is exactly the point. For a private repository, permanently publishing a public record that a build even happened would leak information the organization never intended to disclose. GitHub’s own Sigstore instance uses the identical underlying codebase, so the cryptographic guarantees are the same — it simply keeps the transparency record private to GitHub rather than broadcasting it to the internet.

Stepping back from the cryptographic detail, the entire feature can be understood as three distinct phases.

Every one of these three phases has to happen for the feature to provide any real protection. Generating an attestation that nobody ever checks is equivalent to installing a lock and leaving the key in it — the mechanism exists, but nothing enforces its use.

GitHub supports more than one kind of attestation, and choosing the right one — and the right frequency — is a deliberate design decision, not an afterthought.

Two common predicate types

The most common attestation is a build provenance attestation, which records where and how an artifact was built — the repository, the workflow, the trigger event, and the commit. A second common type is an SBOM attestation (Software Bill of Materials), which instead records exactly which dependencies and components went into the artifact, letting a consumer check for known-vulnerable components without needing to unpack the artifact themselves.

Verification is where the entire feature earns its keep — this is the step that actually protects a consumer from a tampered artifact.

What a verification check actually confirms

When a consumer verifies an attestation, three things are checked at once: that the artifact’s own digest matches the one recorded in the attestation, that the signing certificate chains back to a trusted root (Fulcio’s), and that the signer’s recorded identity — which repository and workflow produced it — matches whatever policy the consumer has decided to trust.

Where verification fits

Verification can happen in several places depending on how much automation an organization wants: manually by a developer using GitHub’s own command-line tooling before running a downloaded binary, automatically inside a deployment pipeline as a gate before promoting an artifact to production, or inside a Kubernetes admission controller that refuses to schedule any container image whose attestation does not pass.

Artifact attestations do not exist in isolation — they are GitHub’s practical implementation of a broader industry framework called SLSA (Supply-chain Levels for Software Artifacts).

SLSA defines a maturity ladder for how trustworthy a build process is, from Level 1 (basic documentation of the build) up through higher levels that require increasingly strong guarantees that the build process itself cannot be tampered with. GitHub-hosted runners combined with the attestation action let a project reach a meaningfully strong level out of the box, because the provenance is generated by GitHub’s own trusted infrastructure rather than by a script the project author controls — removing the possibility that the same person who could tamper with the artifact is also the one vouching for its provenance.

A feature whose entire purpose is trust has to be scrutinized for its own weak points, and GitHub’s design choices reflect several deliberate mitigations.

No long-lived secret to steal

Because every signing key is generated fresh and discarded within minutes, there is no persistent private key sitting in a secrets store waiting to be exfiltrated — a category of risk that has caused real incidents with traditional, long-lived code-signing keys in the past.

Identity is tied to workflow, not to a person

The signing identity embedded in the certificate reflects the exact workflow, repository, and trigger that ran — not a maintainer’s personal account. This means access to sign a release is governed entirely by who can modify the workflow file and trigger it, which is exactly the access an organization already controls through repository and branch protection settings.

Public auditability as a deterrent

For public repositories, every signing event lands in a publicly readable transparency log. Anyone — including the maintainers themselves — can later notice a signing event that should not have happened, because the log is append-only and cannot be quietly edited after the fact.

Weighing both sides honestly helps a team decide how broadly to adopt attestations and how much verification tooling to build around them.

Most of the value — and most of the mistakes — come down to a handful of repeatable choices.

Seeing where this feature has already been adopted makes the abstract cryptography from earlier chapters concrete.

No. The entire point of Sigstore’s keyless signing model is that a fresh key pair is generated automatically for every signing event and discarded within minutes — there is nothing for you to create, store, or rotate.

No. An attestation only proves where and how an artifact was built. It says nothing about whether the code is secure, correct, or free of vulnerabilities — those remain separate checks.

Yes. Public repositories use the Sigstore Public Good Instance and write to a publicly readable transparency log. Private repositories use GitHub’s own Sigstore instance, which is not written to a public log and only federates with GitHub Actions.

No. GitHub’s own guidance is to sign software you expect people to verify — releases, binaries, packages, and container images — and to avoid attesting frequent internal test builds or individual source files.

A consumer uses verification tooling to confirm the artifact’s digest matches the attestation, the signing certificate chains back to a trusted root, and the recorded signer identity matches an expected policy — this can be done manually, in a deployment pipeline, or inside an admission controller.

A failed verification should be treated as a supply-chain integrity break and the artifact should not be used or deployed, since it means the file no longer matches what was actually signed.

Artifact attestations give GitHub Actions a built-in way to cryptographically bind a built artifact to the exact source code and workflow that produced it, using Sigstore’s keyless signing model so no organization ever has to manage a private signing key. A short-lived OIDC identity token, a Fulcio-issued certificate, and a Rekor transparency-log entry together form an unforgeable, auditable chain from commit to artifact. The feature’s real value only appears once consumers actually verify attestations — as a manual check, a deployment gate, or a cluster-wide admission policy — and pin the identity they expect to see, turning a cryptographically valid signature into a meaningful trust decision rather than a checkbox nobody enforces.