Sigstore and Transparency Logs in Compliance Contexts

Every major compliance framework governing software delivery now converges on the same three technical demands: tamper-evident audit trails, non-repudiation of signing events, and verifiable artifact provenance, and the enforcement behind those demands is getting stricter, not looser. SLSA, NIST SSDF (NIST SP 800-218), FedRAMP Rev. 5, SOC 2 Type II, PCI DSS v4.0, and CMMC 2.0 each require some combination of provenance records, integrity verification, and auditable signing events, and none of them treat these as optional add-ons anymore. An SBOM tells an auditor what is inside a piece of software, but composition alone doesn't answer the harder question regulators are starting to ask: was that SBOM tampered with, and does it actually describe the artifact that got deployed? That gap between "here is a list of components" and "here is proof this list matches what shipped" is exactly where an SBOM stops being sufficient on its own.

The urgency behind these requirements stopped being theoretical in September 2025, when the GhostAction attack compromised a GitHub Actions supply chain and showed that CI-level tampering is a live threat vector rather than a hypothetical one. An attacker who can manipulate a build pipeline can produce an artifact that looks legitimate at every downstream checkpoint, unless something independent of that pipeline records the signing event in a form nobody, including the pipeline operator, can quietly rewrite. Rekor was built to solve that specific problem, within a defined scope.

What Rekor Records and Its Cryptographic Guarantees

Rekor is a transparency log, structured as an append-only Merkle tree, and each leaf in that tree records three specific things: a hashed artifact, the signature produced over it, and the certificate or public key used to produce that signature. Those three elements are enough to reconstruct the full signing event later without the log ever storing a private key or any other secret material. The signing flow itself is short-lived by design. An in-memory keypair gets generated, Fulcio issues a short-lived certificate that binds an OIDC identity to the public key, the artifact hash and signature get uploaded to Rekor, and the private key is destroyed immediately after. From that point forward, verification depends on the log entry itself rather than on however the signer happened to store their key, which removes an entire category of risk that traditional signing setups carry for years after a key is issued.

The timestamp attached to each log entry marks the moment Rekor witnessed the signing, and that timestamp is what gives compliance auditors a non-repudiable record of when a specific identity signed a specific artifact. Because the tree is append-only and witnessed, an entry that appears at index N cannot be removed, reordered, or have an earlier entry inserted ahead of it without producing a fork that outside witnesses will catch. The guarantee is bounded, and the boundary matters as much as the guarantee itself. Rekor verifies that a signing event happened, not that the signed artifact is safe. It does not verify that the OIDC identity doing the signing was actually authorized to do so under the organization's own access control policy. It does not verify that the artifact matches the source code it claims to represent. Those three gaps belong entirely to the organization consuming the log, not to Rekor, and any compliance program that treats a Rekor entry as proof of safety or authorization is asking the log to do work it was never built to do.

How the three Sigstore components divide the compliance work

Sigstore's answer to the compliance requirement for signed, timestamped, identity-bound records is architectural rather than procedural: three components, each handling a distinct piece of the problem, working as one integrated system instead of a stack of separately chosen tools. Fulcio acts as the certificate authority, issuing short-lived X.509 certificates that bind an ephemeral signing key to a verified OIDC identity. That binding is what makes non-repudiation possible without forcing an organization to manage long-lived private keys, since a certificate that expires in minutes has almost no window in which it can be stolen and reused later. The public-good instance currently supports Microsoft, Google, and GitHub as OIDC issuers, while self-hosted deployments can use an internal OIDC provider. Traditional GPG-based signing depends on keys that stick around for years. Key rotation and key compromise become permanent operational headaches at any real scale. Short-lived certificates remove that maintenance burden entirely.

Rekor handles the audit trail, recording the signing event and maintaining the tamper-evident structure described above. Cosign is the operational interface teams actually use: it signs container images and artifacts, verifies signatures and attestations, and as of v3.1.1 defaults to the standardized Sigstore bundle format. Cosign has been able to verify npm provenance and GitHub Artifact Attestations with a single tool since v2.4.0. The Update Framework distributes Sigstore's root of trust, Fulcio's root CA certificate and Rekor's public key, providing a secure update channel for the trust anchors themselves. None of this works as a patchwork. Identity, audit record, and operational tooling live inside a single graduated OpenSSF project sharing one trust model, and that matters directly for compliance because it collapses what would otherwise be three separate vendor evidence chains into one an auditor can follow start to finish.

Rekor's log entries satisfy audit trail and non-repudiation requirements

The inclusion proofs, identity-bound timestamps, and witnessed append-only structure built into Rekor map directly onto the audit trail and non-repudiation controls that SLSA, NIST SSDF, and SOC 2 Type II each require, though the mapping is precise rather than total. A SLSA Level 2 or Level 3 provenance statement is only as trustworthy as the signing event recorded in Rekor, and the Rekor log entry proves that a specific CI identity produced that attestation at a specific time. NIST SSDF, laid out in NIST SP 800-218, requires software producers to protect the integrity of what they ship and to produce evidence that they did so. Rekor's inclusion proof supplies that cryptographic evidence, and in-toto attestations wrapped in DSSE supply the structured statement describing which build practices were actually followed.

Transparency log entries carrying timestamps and identity bindings give those auditors direct evidence to review when they're assessing signing controls, rather than forcing them to rely on internal attestations from the engineering team. The non-repudiation property auditors look for follows the same logic: because an OIDC certificate ties a signing event to a specific identity, whether that's a GitHub Actions workflow or a developer's Google account, and Rekor timestamps that event, the signer has no basis to later deny having signed. Self-hosted Sigstore deployments get cited specifically as supporting compliance with SLSA and NIST 800-204D through transparent verification and logging, and the framing behind that citation treats the log as the evidence itself, not a byproduct that happens to exist alongside the workflow.

The mapping stops at the same boundary described earlier. Rekor records that a signing event happened. It does not record whether the signer was authorized to sign under the organization's own internal access control policy, and that authorization evidence has to come from the identity provider's access logs, not from Rekor. An auditor asking "was this person allowed to sign this artifact" needs a different data source than an auditor asking "did this signing event happen and when." Rekor answers the second question with cryptographic certainty. It has nothing to say about the first.

Embedding Sigstore into CI/CD so compliance posture is inherited, not bolted on

None of the guarantees described above matter if signing is a step a developer has to remember to run. Compliance posture only holds up when signing lives inside the golden-path CI template as a default behavior, and making that default the platform team's job, not an individual engineer's habit. The full trust chain runs from source commit through CI build, into a SLSA provenance attestation, through Cosign keyless signing, into the Rekor transparency log, out to an OCI registry carrying both signature and provenance, and finally to a consumer verification step before anything gets deployed. Each link depends on the one before it, and a break anywhere in that chain, an unsigned build step, a registry that strips attestations on push, reopens the exact gap the rest of the chain was built to close.

GitHub Actions makes the early links in that chain approachable in practice. A pipeline can build the artifact, authenticate through OIDC with no stored secrets at all, sign with Cosign, and push with provenance attached, and a team using the slsa-github-generator project alongside GitHub's built-in attestation support can reach SLSA Level 2 for most artifact types in an afternoon. GitHub's own documentation notes that artifact attestations alone deliver SLSA v1.0 Build Level 2 as a baseline, with Level 3 reachable through reusable workflows. Signing an image accomplishes nothing if the cluster receiving it never checks the signature before running the workload, so the closing gate belongs at admission time, where the Sigstore Policy Controller or Kyverno configured with Cosign verification rejects unsigned images before they ever start. Rolling that enforcement out namespace by namespace, rather than flipping it on cluster-wide, keeps a misconfigured policy from taking down more than one team's workloads while the rollout gets tuned.

One coordination gap catches platform teams off guard specifically in multi-architecture environments. When Kubernetes pulls an image, the kubelet resolves the image index down to the manifest matching the node's own architecture, but the admission controller is looking at the pod spec's original image reference, not the resolved per-platform manifest. Teams running mixed-architecture clusters need to account for that mismatch explicitly in their verification tooling, since signature checks can otherwise pass against the wrong artifact reference. Pairing declarative environment manifests, with dependency versions pinned rather than left floating, alongside Sigstore signing closes a related gap between what a developer built and what an auditor can actually verify later, since a signed artifact's provenance is only as meaningful as the reproducibility of the environment that produced it. Finally, the transparency log isn't just a record to consult after the fact. Running rekor-monitor against an organization's own OIDC identity turns unexpected signing events into something detectable in near real time, converting the log from a passive audit trail into an active security control.

What Rekor v2's redesign changes for compliance pipelines

Rekor v2 reached general availability in October 2025, replacing the previous Trillian backend with a tile-based implementation called Trillian-Tessera, making log reads fully cacheable and cutting both storage and egress costs for anyone operating a private instance. That's an infrastructure change with a direct compliance consequence: private and self-hosted operators, including those with air-gap or data-residency requirements, now face a meaningfully lighter operational lift, since the tile-based backend removes the need to run separate Trillian log server and log signer instances. Witnessing, which strengthens the cryptographic guarantee that the log stays append-only, is planned for direct integration into Rekor v2 but was not active at GA launch. Once it lands, it reduces how much compliance trust has to rest on the log operator's own good behavior, since external witnesses provide an independent check against silent rewrites.

Teams building on Rekor v2 need to account for what the redesign dropped. The search index and every entry type except hashedrekord and dsse were removed, and any pipeline built around another entry type or around querying the search API directly needs migration work before it can rely on v2. Client support is currently uneven: Cosign v2.6.0 and above, along with the Go, Python, and Java SDKs, support Rekor v2 upload and verification, but JavaScript and Ruby support was not available at GA. Teams building in either of those languages need to track when that support lands before committing pipelines to v2.

One operational detail deserves direct attention rather than a passing mention: each Rekor v2 log shard now has its own unique URL, distributed through TUF, and pipelines must not hardcode a log URL anywhere in their configuration, because shards rotate periodically and the previous shard gets frozen once rotation happens. A pipeline with a hardcoded URL will silently stop writing to the current log the moment a rotation occurs, and an audit will later turn up the resulting gaps. Rekor v1 keeps running in parallel for now, but new uploads to v1 will eventually be frozen, with one year's advance notice under Sigstore's deprecation guidelines. Compliance teams should treat that year as a deadline to plan around now rather than assuming v1 will remain available indefinitely.

Sigstore's ecosystem reach makes its log entries auditable across registries and artifact types

Because the major open-source registries have standardized on the same transparency log, an organization consuming third-party dependencies can apply the identical verification workflow to upstream packages that it applies to its own artifacts. npm provenance and PyPI attestations are both generally available today, signed through Sigstore's public-good instance, and GitHub Artifact Attestations use the same underlying primitives: a single Cosign v3 installation verifies signatures across all of them without switching tools.

Maven Central extended that reach in January 2025, when it began validating Sigstore signature bundles alongside its existing PGP requirement. Sigstore signatures on Maven Central remain optional rather than mandatory, but the move puts the Java ecosystem on the same trajectory that npm and PyPI have already followed, toward OIDC-backed, transparency-log-anchored provenance as the standard rather than the exception. For an organization building a compliance program, that convergence changes what "auditable supply chain" can mean in practice. A single verification workflow, backed by a single kind of transparency log entry, can now cover an internally built container image, an npm package pulled in as a dependency, and a Java library sourced from Maven Central, without three separate trust models to reconcile. That consistency is what turns Rekor from a tool an individual team adopted into a shared reference point auditors can rely on across an entire dependency graph.