IM Engineer Study Notes
← Back to list
Security & Privacy
#Sigstore#키리스 서명#소프트웨어 공급망 보안#투명성 로그#코드 서명
Last updated · 2026-11-04

Sigstore-Based Keyless Signing of Software Artifacts and the Transparency Log

1. Overview

Sigstore is an open source code-signing system in which a developer, without a long-lived private key, proves an OpenID Connect (OIDC) identity to obtain a short-lived certificate, signs a software artifact with it, and records the signing event in a public transparency log so that anyone can verify and audit it.

As software supply chain attacks have grown, proving "was this binary, container image, or package really produced by a trustworthy party?" has become important. Traditional code signing issued a long-lived private key to a developer or organization, kept it for a long time, and signed artifacts with that key. However, this model carries a heavy operational burden to store, rotate, and revoke keys safely, and if a key leaks, all past and future signatures are threatened at once. Moreover, the mere existence of a signature makes it hard for an outsider to independently confirm when, under which identity, and without forgery it was created.

Sigstore reframes this problem along two axes. First is keyless signing, which removes long-lived key storage. An ephemeral key pair is created only at signing time, and once the organization's OIDC identity (for example a GitHub Actions workflow identity, or a Google/GitHub account) is proven, a certificate authority issues a certificate valid for a few minutes. After signing, the private key is discarded, so the very attack surface of "leakage of a stored key" disappears. Second is transparency, recording the signing event in a public append-only log. Because the signer, certificate, and time are recorded in a tamper-evident log, a verifier can confirm from the log that "the identity was valid at signing time" even after the certificate has expired.

In an essay answer, describing Sigstore merely as a "free signing tool" is insufficient. First, one must distinguish the roles of an SBOM (a list of components), SLSA (evidence of the generation process), and Sigstore (signing and identity proof). Second, rather than asserting "no key means safer," one must explain that trust has merely shifted to the OIDC identity provider and the root-trust distribution system. Third, one should present a staged adoption strategy that balances developer convenience with verification robustness.

A. Background and Necessity

The first background is the structural limit of key management. Signing open source artifacts with GPG or a private PKI requires each project to generate, store, and operate the expiry and revocation of a private key. In reality, keys often remained in plaintext on laptops or in CI settings, or were lost when a maintainer departed. Sigstore reduces both this operational burden and the leakage risk with "a key that exists only briefly while signing and is then thrown away."

The second background is the signing gap in distribution ecosystems. In ecosystems such as npm, PyPI, and container registries, where millions of items are published daily, there was almost no verifiable evidence of which source or build an artifact actually came from. Sigstore binds signatures to CI workflow identities, enabling policy checks such as "this package was built by this repository's protected workflow."

The third background is the demand for independent auditability. Public and financial procurement and various supply chain security regulations and guidelines require that not only the existence of a signature but also "when and by whom it was signed" be traceable after the fact. A public transparency log makes it hard for a signer to later deny having signed (non-repudiation) and opens a path to detect malicious signatures through log monitoring.

B. Goals and Scope

Sigstore's goal is not to block all vulnerabilities but to make signing easy and verifiable so that trust in an artifact's origin can be judged automatically. For example, one can set a policy that "an image deployed to production must be signed with the GitHub Actions identity of an approved repository, and that signature must exist in the public log," and judge it automatically at the verification stage. The scope spans ephemeral key generation, identity proof (OIDC), short-lived certificate issuance, signing, log recording, root-trust distribution, and pre-deployment verification. By contrast, vulnerabilities in the source code itself, the level of build isolation, and runtime protection are not replaced by Sigstore alone, so it must be designed together with SLSA, SBOM, and runtime security.

2. Core Components and Structure of Sigstore

The key to understanding Sigstore is the relationship among Fulcio (a CA that issues short-lived certificates), Rekor (a signing transparency log), Cosign (the client tool), and the root trust distributed by TUF (The Update Framework). The signer uses Cosign to create an ephemeral key, proves identity via OIDC to obtain a short-lived certificate from Fulcio, then signs the artifact and uploads the event to Rekor. The verifier treats the Fulcio root CA and the Rekor public key received via TUF as the basis of trust, and checks the signature, certificate, and log entry together.

flowchart LR
    DEV["Developer / CI Workflow"] --> COSIGN["Cosign Client\nEphemeral Key / Signing"]
    OIDC["OIDC Identity Provider\n(GitHub, Google, etc.)"] --> COSIGN
    COSIGN --> FULCIO["Fulcio\nShort-lived Certificate CA"]
    FULCIO --> COSIGN
    COSIGN --> REKOR["Rekor\nSigning Transparency Log"]
    COSIGN --> ART["Signed Artifact\nImage / Package / Binary"]
    TUF["TUF Root-Trust Distribution\n(Root CA / Log Public Key)"] --> VERIFY["Verifier / Policy Engine"]
    ART --> VERIFY
    REKOR --> VERIFY
    VERIFY --> DECIDE["Allow or Block Deployment"]

A. Fulcio — Short-lived Certificate CA

Fulcio is a certificate authority that, after confirming the signer's OIDC identity, issues a short-lived X.509 certificate valid for minutes that binds that identity to the ephemeral public key. The key point is that the certificate's lifetime is so short that no "long-lived secret" exists. Even after the certificate expires, the validity of the signature is guaranteed by the "signing-time" record left in Rekor. Fulcio places the identity value (for example an email or workflow identifier) in certificate extension fields so a verifier can judge "who signed" from the certificate alone. For instance, when signing in GitHub Actions, the repository, workflow, and trigger information are stamped as the identity, enabling a policy such as "allow only this repository's release workflow as the signer."

B. Rekor — Signing Transparency Log

Rekor is a transparency log that records signing events (signature, certificate, time, and so on) in an append-only, tamper-evident log. Structurally it is based on a Merkle tree, so it cryptographically provides an "inclusion proof" that a given entry is in the log and a "consistency proof" that the log has not altered the past. This complements the weakness of short-lived certificates. The verifier looks not at "is the certificate expired now?" but at "was the certificate valid at the time the signature was recorded in the log?" A public log also serves as a basis for audit and monitoring. An organization can monitor signatures uploaded under its identity and detect identity misuse early if an unexpected entry appears.

C. Cosign — Signing and Verification Client

Cosign is the client tool that ties together Fulcio, Rekor, and OCI registries to perform the actual signing and verification. It can sign and attach not only container images but also ordinary files (blobs) and attestations such as SBOMs and SLSA provenance, handling signatures and supply chain metadata in one system. Keyless mode is the default flow, but depending on the organization's situation it also supports using KMS keys or hardware keys, aiding a gradual transition. During verification it checks the signature, certificate, and log entry together, and lets you state policy conditions such as allowed identities and issuers, preventing loose verification where "any signature passes."

D. TUF Root Trust — the Starting Point of Trust

For verification to hold, the Fulcio root CA certificate and the Rekor public key must be obtained and updated securely, and TUF (The Update Framework) handles this. TUF distributes root material with signed metadata and is designed to withstand man-in-the-middle attacks even through key rotation and revocation. That is, Sigstore's trust has shifted from "the developer's long-lived key" to "the OIDC identity provider plus the root trust distributed via TUF"; it has not disappeared. Therefore, from a professional-engineer perspective, the availability and integrity of the identity provider and the root-trust distribution system become new key control points.

3. The Keyless Signing and Verification Process

Keyless signing proceeds in the order "generate ephemeral key → prove identity → issue short-lived certificate → sign → record in log," and verification traces this in reverse. The sequence below shows the interaction between the signer (developer/CI) and Fulcio, Rekor, and the verifier.

sequenceDiagram
    participant D as "Signer (CI/Developer)"
    participant O as "OIDC Provider"
    participant F as "Fulcio (CA)"
    participant R as "Rekor (Log)"
    participant V as "Verifier"
    D->>D: "Generate ephemeral key pair"
    D->>O: "Request identity authentication"
    O-->>D: "Issue OIDC token"
    D->>F: "Submit token + public key"
    F-->>D: "Issue short-lived cert (identity-bound)"
    D->>D: "Sign artifact"
    D->>R: "Record signature, cert, time"
    R-->>D: "Inclusion proof (log entry)"
    V->>R: "Look up entry, check inclusion proof"
    V->>V: "Verify cert, identity, policy; allow/block"

The most important design point in the signing stage is the immediate discarding of the ephemeral key. Once signing ends, the private key is dropped from memory, so there is nothing left to steal afterward, and trust converges onto "an identity that was valid for a brief moment." In the log-recording stage, the signing time is left in the log, proving "it was valid at that time" even after the certificate later expires. In the verification stage, all of the following are checked: (1) does the signature match the artifact digest, (2) was the certificate issued under the trusted root, (3) do the identity and issuer match the policy, and (4) does the signing event exist in Rekor. If any one of the four is missing, the state becomes "a signature exists but cannot be trusted," so explicitly designing the verification policy is essential.

4. Comparison with Traditional Code Signing and Similar Systems

Sigstore's value becomes clear when we point out why the difference arises from traditional PKI code signing. The traditional approach can offer high trust in a long-lived key but has the weaknesses of storage and revocation burden and broad damage upon leakage. Sigstore removes that burden but in exchange accepts external dependencies on an identity provider, a log, and root trust. Also, just as certificate transparency monitors TLS certificate mis-issuance through a log, Rekor monitors "signing events" through a log, making them conceptual cousins.

Aspect Traditional PKI Code Signing Sigstore (Keyless)
Key storage Requires long-lived private key Ephemeral key, discarded after signing
Basis of trust Issuing CA + stored key OIDC identity + TUF root + log
Leakage impact Broad threat to past/future signatures No stored key, impact localized
Audit Requires a separate system Public transparency log built in
Main burden Key operation and revocation Dependence on identity provider / log availability

As a concrete case, if a container image is keyless-signed with Cosign in GitHub Actions, the repository and workflow identity are stamped into the certificate and the signature is recorded in Rekor. The deployment cluster's policy controller can enforce that only images satisfying "the workflow identity of an approved repository + existence in the log" are admitted. As another case, if an SBOM or SLSA provenance is signed as an attestation and attached to the image, tampering of the supply chain metadata itself is also verified. In this way, Sigstore sits not as a standalone tool but as the signing and identity layer of the supply chain security stack.

5. Deep Dive — Recent Trends and Ecosystem Adoption

Sigstore declared general availability (GA) at SigstoreCon in October 2022 and has since operated under the neutral governance of OpenSSF (under the Linux Foundation). At GA it offered a free public signing service based on the v1.0 releases of Cosign, Fulcio, and Rekor, with a stated availability target around 99.5%. According to public materials, tens of millions of signatures were recorded in the log and tens of thousands of projects adopted it around GA, growing rapidly; because the exact figures differ by announcement date, it is safer to cite them as a trend rather than assert them.

Ecosystem adoption has also broadened. npm began signing support alongside GA, Homebrew, PyPI, and Maven introduced or pursued Sigstore integration, and large projects such as Kubernetes and Python used it for release signing. On the client side, it evolved from specifying a URL per flag toward managing signing settings as configuration, and a bundle format that packages signing results into one was introduced, so formats and tooling keep advancing. That said, detailed release and version behavior changes over time, so for actual adoption one should confirm against that version's release notes. As surrounding tools such as Gitsign for signing git commits and the policy-controller for enforcing policy at deployment have also grown, Sigstore is widening its place as a standard axis for signing and verification across CI/CD.

6. Considerations and Implications

From a professional-engineer perspective, adopting Sigstore must balance the following.

First, control over the trust shift. In exchange for removing long-lived keys, the OIDC identity provider and TUF root trust become new key control points. A misconfiguration of the identity provider or a token theft can directly become a hijacking of signing authority, so identity issuance, scope of privilege, and short-livedness must be designed together.

Second, the explicitness of the verification policy. Passing on the mere fact that "a signature exists" is meaningless. Allowed identity, issuer, repository, and workflow, inclusion in the log, and digest match must all be nailed down as policy, and a gate that blocks deployment on verification failure must be placed in the pipeline.

Third, the availability versus sovereignty trade-off. Depending on a public service lowers the operational burden but exposes one to external availability and policy changes. In closed-network or regulated environments there is the option of operating one's own Fulcio and Rekor, but one must have the capacity to operate root-trust distribution (TUF) and log monitoring.

Fourth, staged adoption and related technologies. Rather than forcing full keyless from the start, first apply signing and verification to core artifacts and expand gradually. Also, because Sigstore is only a signing and identity layer, it must be combined with SBOM (components), SLSA (evidence of the generation process), and runtime security for trust across the entire supply chain to be complete.

Fifth, privacy and log permanence. Because the signing identity (such as an email) is left in the public log and becomes traceable, an identity design that reduces exposure—such as using organization accounts or workflow identities—is needed.

References

In one line: Sigstore signs artifacts with short-lived, OIDC-identity-based certificates (Fulcio) without long-lived private keys and records the event in a public transparency log (Rekor), reducing key-leakage risk while letting anyone verify and audit a signature's origin and time—a software supply chain signing system.