Cosign vs GPG: artifact とコンテナへの署名

著者 Kaveh Alemi·Latchkey

どちらも artifact に署名しますが、異なる時代のためのものです。GPG は自分で管理する長寿命の鍵を持つ、長年使われてきた汎用署名ツールで、Cosign (Sigstore) はコンテナとサプライチェーンのために作られ、OIDC 経由の keyless 署名と公開の透明性ログを備えます。

Cosign と GPG はどちらも、artifact があなたから来て改ざんされていないことを証明します。GPG は汎用的で成熟していますが鍵管理をあなたに委ねます。Cosign はコンテナイメージと OCI artifact を対象とし、長寿命の鍵を保持せずに署名できます。ここでは率直な比較を示します。

	Cosign	GPG
対象	コンテナ、OCI artifact、サプライチェーン	汎用の署名/暗号化
鍵	keyless (OIDC) または鍵ペア	自分で管理する長寿命の鍵ペア
透明性ログ	あり (Rekor)	なし
コンテナサポート	第一級 (digest でイメージに署名)	手動、コンテナネイティブではない
鍵管理の負担	keyless では低い	高い (ローテーション、配布)
成熟度	より新しく、広く採用	数十年前から、ユビキタス

鍵管理 vs keyless

GPG は、生成、保護、ローテーション、配布を行う長寿命の秘密鍵に依存します。これは強力ですが運用上重く、特に署名鍵の保管がリスクとなる短命の CI runner ではなおさらです。Cosign の keyless 署名は OIDC アイデンティティ (例えば CI ジョブのアイデンティティ) に紐づいた短命の証明書を使うため、漏洩する長寿命の secret がなく、各署名は Rekor 透明性ログに記録されます。

設計からしてコンテナネイティブ

Cosign は digest でコンテナイメージに署名・検証し、registry 内でイメージと並べて署名を保存します。これは GPG が決して設計されていなかったことです。OCI イメージとサプライチェーンの attestation (SBOM、provenance) には Cosign が自然な選択です。GPG は従来のワークフローでのリリース、コミット、パッケージへの署名に依然として優れています。

CI では

Cosign の keyless 署名は CI と完璧に組み合わさります。runner の OIDC token が署名者のアイデンティティとなり、管理すべき secret がなく、検証ポリシーは deploy 前に署名を要求できます。すでに GPG でリリースに署名しているなら、それを並行して続けられます。

Decide with your own repository

Both tools in a mature category can do the job. What differs is behaviour on your codebase, which takes an afternoon to measure and beats any feature table.
Benchmark the cold path with no cache. Warm local runs favour whatever you already have cached, which is the one condition CI never has.
Price the switching cost honestly: lockfile or config format, stricter resolution surfacing latent bugs, and every developer plus every runner having to move together.

結論

コンテナイメージとサプライチェーンの artifact への署名、特に CI での keyless 署名と透明性ログには Cosign を、汎用署名、リリース artifact、コミットには GPG を維持しましょう。両者は異なるニーズに対応し、しばしば共存します。

よくある質問

Cosign vs GPG: Signing Artifacts and Containers?

Cosign and GPG both prove an artifact came from you and was not tampered with. GPG is general and mature but puts key management on you; Cosign targets container images and OCI artifacts and can sign without you holding long-lived keys. Here is the honest comparison.

Key management vs keyless?

GPG relies on long-lived private keys you generate, protect, rotate, and distribute, which is powerful but operationally heavy, especially in ephemeral CI runners where storing a signing key is risky.

Container-native by design?

Cosign signs and verifies container images by digest and stores signatures alongside images in the registry, which GPG was never designed to do. For OCI images and supply-chain attestations (SBOMs, provenance), Cosign is the natural fit. GPG remains excellent for signing releases, commits, and packages in traditional workflows.

In CI?

Cosign keyless signing pairs perfectly with CI: the runner OIDC token becomes the signer identity, with no secret to manage, and verification policies can require signatures before deploy. If you already sign releases with GPG, that can continue in parallel.

Which should I choose?

Choose Cosign for signing container images and supply-chain artifacts, especially with keyless CI signing and transparency logging; keep GPG for general signing, release artifacts, and commits. They address different needs and often coexist.