Sigstore for Software Packages: How to Verify Digital Signatures Without Manual Key Management

Digital signatures help package users answer two practical questions: has this file changed since it was signed, and was it signed by the identity the project says it uses? Traditional signing methods can provide those answers, but they often depend on long-lived private keys, public-key distribution, expiry dates, revocation procedures and careful storage. Sigstore takes a different approach. It lets a developer or automated release workflow prove an identity through OpenID Connect, creates a short-lived signing key, binds that key to a short-lived certificate and records the signing event in a public transparency log. For users, this shifts verification away from manually collecting and maintaining individual public keys while preserving a cryptographic link between a package, a signer and a specific signing event.

Why Sigstore Changes the Way Package Signatures Are Verified

With a conventional long-lived signing key, the maintainer has to protect the private key for months or years and make the corresponding public key available to everyone who needs to verify releases. That process can work well, but it creates operational work that has little to do with the package itself. Keys can expire, be lost, be copied to insecure machines or remain trusted after a maintainer leaves a project. A user also has to decide where a public key came from and whether the key still belongs to the person or organisation named on it. These problems are manageable for experienced release teams, yet they are easy to overlook in smaller open-source projects and automated build systems.

Sigstore’s identity-based signing model reduces that burden by creating an ephemeral key for a signing operation rather than asking the signer to maintain one permanent secret. The signer proves an identity through an OpenID Connect issuer such as GitHub, GitLab, Google or Microsoft. Fulcio, Sigstore’s certificate authority, checks that identity information and issues a short-lived certificate that binds the identity to the temporary public key. The private key exists only briefly and is discarded after use. A verifier therefore does not need the maintainer to publish and rotate a personal public key indefinitely. The important information becomes the expected signer identity, the identity issuer and the trusted Sigstore roots used to validate the certificate and transparency evidence.

The signing event is also recorded through Rekor, Sigstore’s transparency log. This matters because the certificate is deliberately short-lived: verification may happen weeks or years after that certificate has expired. The recorded evidence shows that the signature existed while the certificate was valid, allowing a verifier to check the historical signing event rather than requiring a currently valid personal certificate. Sigstore clients obtain trusted root material through The Update Framework, commonly shortened to TUF, so root certificates and log keys can be updated in a controlled way. In practical terms, package verification becomes closer to checking an expected identity and a recorded event than maintaining a personal address book of signing keys.

What a Valid Sigstore Signature Actually Proves

A successful Sigstore verification provides strong evidence that the package being checked matches the data that was signed. If even a small part of the file changes, its cryptographic digest changes and the signature check should fail. Verification also checks the certificate and the identity information carried with it, so the user can require a specific email address, service identity or automated workflow rather than accepting any valid Sigstore signer. This is an important distinction. The goal is not simply to see a message saying that some signature is valid; the goal is to confirm that the package was signed by the identity the project has explicitly designated for releases.

For keyless signatures, timing evidence is part of the trust decision. A short-lived certificate may be expired when a user checks an older package, but that does not automatically make the old signature invalid. Sigstore bundles can carry the signature, certificate, timestamp information and proof associated with the transparency log entry. Cosign uses that evidence to determine whether the signing event occurred during the certificate’s valid period and whether the recorded information is consistent with the package being checked. This is one reason the bundle format is useful for ordinary files: the verifier receives the verification material together instead of reconstructing the signing event from several unrelated files.

A valid signature does not prove that a package is secure, bug-free or suitable for a particular system. It proves facts about integrity and signing identity, not the quality of the code before it was signed. If an authorised maintainer account is compromised, or a legitimate release workflow builds malicious source code, a cryptographically valid signature can still be produced. Package users should therefore treat Sigstore as one layer of software-supply-chain assurance. Provenance attestations, source review, dependency controls, vulnerability scanning and reproducible-build techniques answer different questions and can complement signature verification rather than being replaced by it.

How to Verify a Sigstore-Signed Software Package in Practice

Verification starts with three pieces of information: the exact package file, the Sigstore verification material associated with that file and the identity you expect to have signed it. For a normal file or release archive, the verification material is commonly supplied as a Sigstore bundle with a name ending in .sigstore.json. The expected identity should come from the project’s own release documentation, repository or security guidance, not from an untrusted download page that happens to host the package. You also need the expected OpenID Connect issuer. For automated releases, the identity may be a workflow URI rather than a human email address, which makes the build process itself part of the verification policy.

Cosign is the main Sigstore command-line tool for signing and verifying general software files. A typical check uses cosign verify-blob with the package file, its bundle, the expected certificate identity and the expected OIDC issuer. The important part is not memorising the command syntax; it is supplying restrictive identity values. A command that accepts any certificate identity may confirm that somebody used Sigstore, but it does not confirm that the expected project signed the release. In a well-defined release process, the project documents the exact identity or workflow pattern that consumers should trust, and verification is configured to reject signatures from other identities even when those signatures are cryptographically valid.

When Cosign verifies a bundle, it checks more than a detached signature. It validates the signature against the package, checks the signing certificate and identity requirements, and validates the relevant transparency or timestamp evidence using trusted Sigstore material. A failed check should be investigated before the package is installed or promoted into a production environment. Failure does not automatically prove tampering: an incorrect identity value, an old local trust configuration, a mismatched bundle or a damaged download can also cause verification to fail. The useful rule is simple: a release should not be treated as verified until the cryptographic check and the expected-identity check both succeed for the exact file being used.

Verification in npm, PyPI and Maven Central

Some package ecosystems now expose Sigstore-backed information through their own tooling, so users do not always have to run a raw Cosign command. npm provenance can link a published package to its source repository and build environment, while npm’s signature audit checks registry signatures and available provenance attestations for installed dependencies. The command npm audit signatures is intended for this purpose. npm documentation also recommends using a current npm CLI because attestation formats and verification features continue to evolve. This is a useful example of Sigstore becoming an underlying trust mechanism while ordinary package-management tools present the verification result in a form that developers can use during routine dependency checks.

PyPI supports digital attestations under PEP 740 and combines them with Trusted Publishing. A package released through an authorised automated publisher can carry an attestation showing which publishing identity was used. PyPI makes those attestations available through its index APIs, and the pypi-attestations tool can verify a distribution against the recorded provenance and an expected source repository. This gives Python users a way to check that a wheel or source distribution was published through the expected trusted workflow and that the file matches the signed statement. PyPI is careful to distinguish this from a judgement about whether the package is trustworthy: attestation confirms origin-related facts, not the absence of harmful code.

Maven Central illustrates why Sigstore adoption should not be treated as identical across every package ecosystem. Its current publishing requirements still require GPG or PGP signatures for deployed files. At the same time, Central supports accompanying .sigstore.json files and validates Sigstore signatures when publishers provide them. That means a Java library may have both the traditional .asc signature and Sigstore verification material. For consumers, the practical lesson is to follow the rules and metadata of the package source they actually use. Sigstore can remove manual key handling from workflows designed around identity-based signing, but it does not erase existing signature requirements where an ecosystem continues to require long-lived PGP keys.

Where Keyless Verification Fits in a 2026 Release Process

Sigstore is especially useful when software is released automatically from a continuous-integration service that can issue an OIDC identity token. Instead of storing a long-lived signing key as a build secret, the release job receives a short-lived identity token, obtains a short-lived signing certificate and signs the output during that run. The identity can describe the repository and workflow that performed the release, giving consumers a concrete value to verify. This design reduces the consequences of accidentally exposing a permanent signing key because there may be no reusable private key stored in the build settings at all. It also makes routine key rotation much less central to everyday release administration.

The verifier still needs a clear trust policy. Removing manual key management does not mean removing trust decisions. A team must decide which repository, workflow, service account or maintainer identity is authorised to sign a package. Verification should then require that identity and its expected issuer. If a project changes its release workflow, moves repositories or changes the identity used for signing, consumers may need to update the accepted policy. This is a healthier kind of maintenance than distributing a new personal public key, but it remains maintenance. The benefit is that the policy describes who or what is authorised to release software, while the short-lived cryptographic material is generated and retired automatically.

Tooling and trust roots also need to stay current. Sigstore distributes public trust material through TUF so clients can receive changes to certificate-authority and transparency-log keys without asking every package maintainer to redistribute verification keys. Cosign 3.x uses Sigstore bundles as the default way to carry signature verification data in several common workflows, which makes package signatures easier to move with release files and easier for other Sigstore software to consume. Organisations that archive releases should therefore preserve the package and its associated bundle together. Keeping a verified copy of the relevant release metadata is valuable when a package must be checked again long after the original signing certificate has expired.

Practical Limits and Sensible Checks Before Trusting a Release

The most important limitation is that identity-based signing moves the security boundary towards the identity provider and the release workflow. If an attacker gains control of an authorised developer account or a workflow with permission to request an identity token, the attacker may be able to create a valid-looking signed release. The transparency log helps because signing events are publicly auditable and unexpected identities or events can be detected, but logging is not the same as prevention. Projects should still protect maintainer accounts with strong authentication, restrict release permissions, review workflow changes and separate ordinary development permissions from the ability to publish official packages.

Provenance matters when users need to know more than who signed a final file. A basic signature can show that an identity approved a particular package, but it does not automatically show which source revision produced the package or how the build was performed. Attestations can add that context by linking a release to a repository, workflow or build statement. npm provenance and PyPI attestations are practical examples. For higher-assurance environments, teams can combine Sigstore verification with SLSA provenance, software bills of materials, dependency policies and reproducible builds. Each control narrows a different uncertainty instead of asking one digital signature to answer every supply-chain question.

A sensible 2026 verification policy is therefore straightforward: obtain packages from the expected source, verify the exact file, require the documented signer identity and issuer, preserve the associated Sigstore bundle where one is provided, and check provenance when the ecosystem makes it available. If the package source still requires PGP, continue to verify that signature as well rather than assuming Sigstore has replaced it. The main advantage of Sigstore is not that trust becomes automatic. It is that software projects can use short-lived credentials and auditable identities instead of asking every maintainer and every consumer to manage a web of long-lived signing keys by hand, while still retaining a verifiable record of who signed what and when.