情報管理技術士 学習ノート
← 一覧へ
セキュリティ・個人情報
#Sigstore#키리스 서명#소프트웨어 공급망 보안#투명성 로그#코드 서명
最終更新 · 2026-11-04

Sigstoreによるソフトウェアアーティファクトのキーレス署名と透明性ログ

1. 概要

Sigstoreは、開発者が長期保管する秘密鍵なしに、OpenID Connect(OIDC)の身元を根拠として短命の証明書を発行してもらい、ソフトウェアアーティファクトに署名し、その署名イベントを公開透明性ログ(transparency log)に記録して、誰もが検証・監査できるようにするオープンソースのコード署名体系である。

ソフトウェアサプライチェーン攻撃が増えるにつれ、「このバイナリ・コンテナイメージ・パッケージを本当に信頼できる主体が作ったのか」を証明する問題が重要になった。 従来のコード署名は、開発者や組織が秘密鍵を発行してもらい長期間保管し、その鍵で成果物に署名する方式であった。 しかしこのモデルは鍵を安全に保管・ローテーション・廃棄する運用負担が大きく、鍵が漏えいすると過去・未来のすべての署名が一度に脅かされる。 さらに「署名が存在する」という事実だけでは、その署名がいつ、どの身元で、偽造なく作られたのかを外部から独立に確認するのは難しい。

Sigstoreはこの問題を二つの軸で再構成する。 第一は、長期鍵の保管をなくすキーレス(keyless)署名である。署名時点のみに一時的な鍵ペアを作り、組織のOIDC身元(例: GitHub Actionsワークフロー身元、Google・GitHubアカウント)を証明すると、認証局が数分間だけ有効な短命証明書を発行する。署名が終われば秘密鍵は廃棄されるため、「保管された鍵の漏えい」という攻撃面そのものが消える。 第二は、署名イベントを公開の追記専用(append-only)ログに残す透明性である。署名主体・証明書・時刻が改ざん耐性のあるログに記録されるため、検証者は証明書がすでに失効していても「署名当時にその身元が有効だった」ことをログで確認できる。

論述解答でSigstoreを単なる「無料の署名ツール」と説明しては不十分である。 第一に、SBOM(構成要素の一覧)・SLSA(生成過程の証拠)・Sigstore(署名・身元証明)の役割の違いを区別しなければならない。 第二に、「鍵がないからより安全だ」と断定せず、信頼がOIDC身元プロバイダとルート信頼配布体系へ移動しただけである点を説明すべきである。 第三に、開発者の利便性と検証の堅牢性をともに考慮した段階的導入戦略を提示すべきである。

A. 登場背景と必要性

第一の背景は鍵管理の構造的限界である。 GPGや私設PKIでオープンソース成果物に署名するには、各プロジェクトが秘密鍵を生成・保管し、失効・回収を運用しなければならない。 現実には鍵がノートPCやCI設定に平文で残ったり、担当者が去る際に紛失される事例が多かった。 Sigstoreは「署名するときだけ一瞬存在してすぐ捨てられる鍵」で、この運用負担と漏えいリスクを同時に減らす。

第二の背景は配布エコシステムの署名の空白である。 npm、PyPI、コンテナレジストリのように毎日数百万件が配布されるエコシステムで、成果物が実際にどのソース・ビルドから来たのかを検証可能な証拠がほとんどなかった。 SigstoreはCIワークフローの身元に署名を結び付け、「このパッケージはこのリポジトリの保護されたワークフローが作った」といったポリシー検証を可能にする。

第三の背景は独立した監査可能性の要求である。 公共・金融の調達や各種のサプライチェーンセキュリティ規制・ガイドラインは、署名の有無だけでなく「いつ誰が署名したか」を事後に追跡できることを求める。 公開透明性ログは、署名主体が事後に「署名した覚えはない」と否認しにくくし(否認防止)、悪意ある署名が紛れ込めばログ監視で検知する道を開く。

B. 目標と範囲

Sigstoreの目標はすべての脆弱性を防ぐことではなく、署名を容易かつ検証可能にして成果物の出所信頼を自動判定できるようにすることである。 例えば「本番に配布されるイメージは承認されたリポジトリのGitHub Actions身元で署名され、その署名が公開ログに存在しなければならない」というポリシーを立て、検証段階で自動的に判定できる。 範囲は、一時鍵の生成、身元証明(OIDC)、短命証明書の発行、署名、ログ記録、ルート信頼の配布、配布前の検証へとつながる。 一方、ソースコード自体の脆弱性、ビルド隔離の水準、ランタイム保護はSigstore単独では代替しないため、SLSA・SBOM・ランタイムセキュリティとともに設計すべきである。

2. Sigstoreの中核構成要素と構造

Sigstoreを理解する鍵は、Fulcio(短命証明書発行CA)、Rekor(署名透明性ログ)、Cosign(クライアントツール)、そしてTUF(The Update Framework)で配布されるルート信頼の関係である。 署名者はCosignで一時鍵を作り、OIDCで身元を証明してFulcioから短命証明書を受け取った後、アーティファクトに署名してそのイベントをRekorに上げる。 検証者はTUFで受け取ったFulcioルートCAとRekor公開鍵を信頼の基準とし、署名・証明書・ログ項目をともに検査する。

flowchart LR
    DEV["開発者 / CIワークフロー"] --> COSIGN["Cosignクライアント\n一時鍵生成・署名"]
    OIDC["OIDC身元プロバイダ\n(GitHub・Googleなど)"] --> COSIGN
    COSIGN --> FULCIO["Fulcio\n短命証明書発行CA"]
    FULCIO --> COSIGN
    COSIGN --> REKOR["Rekor\n署名透明性ログ"]
    COSIGN --> ART["署名済みアーティファクト\nイメージ・パッケージ・バイナリ"]
    TUF["TUFルート信頼配布\n(ルートCA・ログ公開鍵)"] --> VERIFY["検証者 / ポリシーエンジン"]
    ART --> VERIFY
    REKOR --> VERIFY
    VERIFY --> DECIDE["配布の許可または遮断"]

A. Fulcio — 短命証明書発行CA

Fulcioは、署名者のOIDC身元を確認した後、その身元を一時公開鍵に結び付けた数分程度の短命X.509証明書を発行する認証局である。 核心は、証明書の寿命が極めて短く「長期保管される秘密」が存在しない点である。証明書が失効しても署名の有効性は、Rekorに残る「署名当時の時刻」の記録で保証される。 Fulcioは身元値(例: メール、ワークフロー識別子)を証明書の拡張フィールドに収め、検証者が「誰が署名したか」を証明書だけで判定できるようにする。 例えばGitHub Actionsで署名すると、リポジトリ・ワークフロー・トリガー情報が身元として刻まれるため、「このリポジトリのreleaseワークフローのみを署名主体として許可」するポリシーが可能である。

B. Rekor — 署名透明性ログ

Rekorは、署名イベント(署名値・証明書・時刻など)を追記専用・改ざん耐性のあるログに記録する透明性ログである。 構造的にはマークルツリー(Merkle tree)に基づくため、特定の項目がログに含まれているという「包含証明(inclusion proof)」と、ログが過去を改変していないという「一貫性証明」を暗号学的に提供する。 これにより短命証明書の弱点を補う。検証者は「証明書が今失効しているか」ではなく「署名がログに記録されたその時点で証明書が有効だったか」を見る。 また公開ログは監査・監視の根拠となる。組織は自らの身元で上がった署名を監視し、予期しない項目が見えれば身元の悪用を早期に検知できる。

C. Cosign — 署名・検証クライアント

Cosignは、Fulcio・Rekor・OCIレジストリを束ねて実際の署名と検証を行うクライアントツールである。 コンテナイメージだけでなく一般ファイル(blob)、SBOM・SLSA provenanceのような証明書(attestation)も署名・添付でき、署名とサプライチェーンメタデータを一つの体系で扱う。 キーレスモードが基本の流れだが、組織の状況に応じてKMS鍵やハードウェア鍵を使う方式も支援し、段階的な移行を助ける。 検証時には署名・証明書・ログ項目をともに確認し、許可する身元・発行者などのポリシー条件を明示して、「署名さえあれば通過」する緩い検証を防ぐ。

D. TUFルート信頼 — 信頼の出発点

検証が成立するには、FulcioルートCA証明書とRekor公開鍵を安全に取得・更新しなければならないが、これを担うのがTUF(The Update Framework)である。 TUFは署名されたメタデータでルート資料を配布し、鍵のローテーション・失効にあっても中間者攻撃に耐えるよう設計されている。 すなわちSigstoreの信頼は「開発者の長期鍵」から「OIDC身元プロバイダ + TUFで配布されるルート信頼」へ移動したのであって、消えたのではない。 したがって技術士の観点では、身元プロバイダ・ルート信頼配布体系の可用性と完全性が新たな核心統制点となる。

3. キーレス署名・検証プロセス

キーレス署名は「一時鍵の生成 → 身元証明 → 短命証明書の発行 → 署名 → ログ記録」の順で進み、検証はこれを逆にたどる。 以下のシーケンスは、署名主体(開発者/CI)とFulcio・Rekor・検証者の間の相互作用を示す。

sequenceDiagram
    participant D as "署名者(CI/開発者)"
    participant O as "OIDCプロバイダ"
    participant F as "Fulcio(CA)"
    participant R as "Rekor(ログ)"
    participant V as "検証者"
    D->>D: "一時鍵ペアの生成"
    D->>O: "身元認証の要求"
    O-->>D: "OIDCトークンの発行"
    D->>F: "トークン + 公開鍵の提出"
    F-->>D: "短命証明書の発行(身元バインド)"
    D->>D: "アーティファクトへの署名"
    D->>R: "署名・証明書・時刻の記録"
    R-->>D: "包含証明(ログ項目)"
    V->>R: "署名項目の照会・包含証明の確認"
    V->>V: "証明書・身元・ポリシー検証後に許可/遮断"

署名段階で最も重要な設計点は一時鍵の即時廃棄である。 署名が終われば秘密鍵をメモリから捨てるため、以後に奪取される対象がなく、信頼は「短い瞬間だけ有効だった身元」に収束する。 ログ記録段階では署名時刻がログに残り、後で証明書が失効しても「その時点で有効だった」ことを証明する。 検証段階では、(1)署名がアーティファクトのdigestと一致するか、(2)証明書が信頼ルートの下で発行されたか、(3)身元・発行者がポリシーに合致するか、(4)署名イベントがRekorに存在するか、をすべて確認する。 四つのうち一つでも欠ければ「署名はあるが信頼できない」状態になるため、検証ポリシーを明示的に設計することが核心である。

4. 従来のコード署名・類似体系との比較

Sigstoreの価値は、従来のPKIコード署名との差が生じる理由を押さえるときに明確になる。 従来方式は長期鍵の信頼度が高くなり得るが、保管・回収の負担と漏えい時の広範な被害が弱点である。 Sigstoreはその負担をなくす代わりに、身元プロバイダ・ログ・ルート信頼という外部依存を受け入れる。 また、certificate transparency(証明書透明性)がTLS証明書の誤発行をログで監視するのと同様に、Rekorは「署名イベント」をログで監視するという点で概念的ないとこの関係である。

区分 従来のPKIコード署名 Sigstore(キーレス)
鍵の保管 長期秘密鍵の保管が必要 一時鍵、署名後に廃棄
信頼の根拠 発行CA + 保管鍵 OIDC身元 + TUFルート + ログ
漏えいの影響 過去・未来の署名に広範な脅威 保管鍵なし、影響が局所化
監査 別体系が必要 公開透明性ログを内蔵
主な負担 鍵の運用・回収 身元プロバイダ・ログ可用性への依存

具体事例として、コンテナイメージをGitHub ActionsでCosignによりキーレス署名すると、リポジトリ・ワークフロー身元が証明書に刻まれ、署名がRekorに記録される。 配布クラスタのポリシーコントローラは、「承認されたリポジトリのワークフロー身元 + ログ存在」を満たすイメージのみを許可するよう強制できる。 別の事例として、SBOMやSLSA provenanceをattestationとして署名しイメージに添付すれば、サプライチェーンメタデータ自体の改ざんもともに検証される。 このようにSigstoreは単独のツールではなく、サプライチェーンセキュリティスタックの署名・身元の層として位置する。

5. 深掘り — 最新動向とエコシステム適用

Sigstoreは2022年10月のSigstoreConで一般公開(GA)を宣言し、以後OpenSSF(Linux Foundation傘下)の中立的ガバナンスの下で運用されている。 GA時点でCosign・Fulcio・Rekorのv1.0を基盤に無料の公開署名サービスを提供し、99.5%程度の可用性目標を掲げた。 公開資料によればGA前後で数千万件の署名がログに記録され、数万のプロジェクトが使用するなど急速に採用されたが、具体的な数値は発表時点ごとに異なるため、断定するより趨勢として引用するのが安全である。

エコシステムの適用も広がった。 npmはGAとともに署名支援を始め、Homebrew・PyPI・MavenなどもSigstore連携を導入・推進し、Kubernetes・Pythonのような大型プロジェクトがリリース署名に活用した。 クライアント側では、フラグごとにURLを指定する方式から署名設定を構成で管理する方向へ進化し、署名結果を一つに束ねるバンドル(bundle)形式が導入されるなど、フォーマット・ツールが発展し続けている。 ただし詳細なリリース・バージョンの挙動は時点によって変わるため、実際の適用時には当該バージョンのリリースノートで確認すべきである。 gitコミット署名用のGitsign、配布時にポリシーを強制するpolicy-controllerのように周辺ツールもともに成長し、SigstoreはCI/CD全般の署名・検証の標準軸として位置を広げている。

6. 考慮事項および示唆点

技術士の観点では、Sigstoreの導入は次を均衡よく考慮すべきである。

第一に、信頼の移動(trust shift)に対する統制である。長期鍵をなくした代わりに、OIDC身元プロバイダとTUFルート信頼が新たな核心統制点となる。身元プロバイダの設定誤りやトークン奪取がそのまま署名権限の奪取につながり得るため、身元の発行・権限範囲・短命性をともに設計すべきである。

第二に、検証ポリシーの明示性である。「署名が存在する」だけで通過させては意味がない。許可する身元・発行者・リポジトリ・ワークフロー、ログ包含の有無、digest一致をすべてポリシーとして固定し、検証失敗時に配布を遮断するゲートをパイプラインに入れるべきである。

第三に、可用性・主権のトレードオフである。公開サービスに依存すれば運用負担は減るが、外部の可用性・ポリシー変化にさらされる。閉域網・規制環境では自前のFulcio・Rekorを運用する選択肢があるが、ルート信頼配布(TUF)とログ監視を運用する能力を備えねばならない。

第四に、段階的導入と連携技術である。最初から全面キーレスを強制するより、まず中核成果物から署名・検証を適用し、徐々に拡大する。またSigstoreは署名・身元の層にすぎないため、SBOM(構成要素)・SLSA(生成過程の証拠)・ランタイムセキュリティと結合してこそ、サプライチェーン全区間の信頼が完成する。

第五に、プライバシー・ログの永続性である。署名身元(メールなど)が公開ログに残り追跡可能になるため、組織アカウント・ワークフロー身元を使うなど露出を減らす身元設計が必要である。

参考資料

一言まとめ: Sigstoreは長期秘密鍵なしにOIDC身元に基づく短命証明書でアーティファクトに署名(Fulcio)し、そのイベントを公開透明性ログ(Rekor)に残すことで、鍵漏えいリスクを減らしつつ署名の出所・時点を誰もが検証・監査できるようにするソフトウェアサプライチェーン署名体系である。