コンテナイメージをCosignで署名検証する｜Sigstoreによるサプライチェーン保護の導入と鍵管理の選択

コンテナのサプライチェーン攻撃が現実の脅威となった経緯

2020年のSolarWinds事件以降、ソフトウェアのビルド・配布パイプラインそのものを標的にした攻撃が急増しました。コンテナエコシステムにおいても、公開レジストリに悪意ある改ざんイメージが混入するケースや、CI/CDパイプラインの設定ミスを突いて正規イメージを差し替える手口が報告されています。

問題の本質は「どのイメージが本当に信頼できるビルドシステムから来たものか」を実行時に検証する仕組みがなかった点にあります。コンテナイメージのダイジェスト（SHA-256）は改ざん検知には有効ですが、そのダイジェスト自体が正規のものかどうかを保証するには、別途「署名」と「検証」のレイヤーが必要です。

こうした課題に応えるために登場したのが、Linux Foundation 傘下の Sigstore プロジェクトです。2022年以降、CNCF（Cloud Native Computing Foundation）のエコシステムに広く取り込まれ、2026年現在では主要なコンテナランタイムやKubernetes Policy Controllerとの統合が成熟しています。

Sigstore と Cosign の役割を整理する

Sigstore は、コード署名のインフラを無償で提供するオープンソースプロジェクトです。主要コンポーネントとして、署名ツールの Cosign、OpenID Connect（OIDC）トークンと署名を紐づける Fulcio（証明書発行局）、そして署名ログを改ざん耐性のある形で記録する Rekor（透過性ログ）の3つで構成されています。

Cosign はこの中でもっとも直接操作する CLI ツールです。コンテナイメージへの署名付与、SBOM（ソフトウェア部品表）や脆弱性スキャン結果のアタッチ、そして署名検証まで一手に担います。署名はイメージ本体を変更することなく、同一レジストリ内の OCI アーティファクトとして保存されるため、既存のレジストリをそのまま使い続けられます。

運用者が最初に理解しておくべき点は、Cosign には「鍵ペアを使う方式」と「キーレス（OIDC）方式」の2種類があり、鍵管理の設計が運用コストと信頼モデルに大きく影響するということです。

鍵管理の選択：キーレス署名と鍵ペア署名の違い

キーレス署名は、GitHub Actions や GitLab CI などの CI 環境が発行する OIDC トークンを Fulcio に提示し、その場限りの短命証明書（有効期限10分程度）を取得して署名する方式です。秘密鍵を長期保存・管理する必要がなく、署名と CI パイプラインの実行ID・リポジトリURLが紐づくため、「どのリポジトリのどのワークフローが署名したか」を Rekor で後から検証できます。

一方、鍵ペア署名は従来の PKI に近い考え方で、cosign generate-key-pair で生成した秘密鍵で署名し、公開鍵で検証します。オフライン環境や、外部 OIDC プロバイダへの依存を避けたいエアギャップ構成に適しています。ただし秘密鍵の安全な保管（KMS や HSM の利用）が必須となり、ローテーション運用も設計に含める必要があります。

現場での選択基準をまとめると、次のように整理できます。

• クラウドCI（GitHub Actions / GitLab CI）＋パブリックレジストリ：キーレス署名が最もシンプルで鍵管理コストがゼロ
• オンプレCI＋プライベートレジストリ：鍵ペア署名＋KMS（AWS KMS / GCP KMS / HashiCorp Vault）の組み合わせが現実的
• エアギャップ環境：Rekor ログが使えないため、鍵ペア方式＋内部 CA による自前 Fulcio の構築を検討する

Cosign による署名と検証の基本手順

ここでは GitHub Actions のキーレス署名を例に、実際の操作の流れを確認します。

まず Cosign のインストールです。2026年現在の最新安定版は v2 系で、Homebrew・APT・GitHub Releases からバイナリを取得できます。CI 環境では sigstore/cosign-installer アクションを使うと特定バージョンの固定が容易です。

# GitHub Actions ワークフロー内（抜粋）
- uses: sigstore/cosign-installer@v3
  with:
    cosign-release: 'v2.4.1'

- name: Sign image
  run: |
    cosign sign --yes \
      ghcr.io/example/myapp@${{ steps.build.outputs.digest }}

--yes フラグは対話確認をスキップするためのものです。CI 環境では必須と考えてください。署名対象はタグではなくダイジェスト（@sha256:...）で指定するのが鉄則です。タグは後から上書きできるため、タグを署名対象にすると保護として意味をなしません。

検証は cosign verify コマンドで行います。キーレス署名の場合、検証時に「期待する証明書のSANパターン（OIDC のサブジェクト）」と「発行元 Issuer URL」を明示することが重要です。

cosign verify \
  --certificate-identity-regexp="^https://github.com/example/myapp/.github/workflows/" \
  --certificate-oidc-issuer="https://token.actions.githubusercontent.com" \
  ghcr.io/example/myapp@sha256:abc123...

これらのフラグを省略すると「署名は存在するが誰が署名したかは確認していない」状態になり、サプライチェーン保護として不十分です。多くの現場でこの点が見落とされやすく、チェックリストに明示しておくことが推奨されます。

Policy Controller による Kubernetes での強制適用

Cosign による手動検証は有用ですが、本番クラスターでのサプライチェーン保護を確実にするには、未署名・不正署名のイメージがデプロイされる前に自動でブロックする仕組みが必要です。この役割を担うのが Sigstore の Policy Controller です。Kubernetes の Admission Webhook として動作し、Pod の作成・更新時にイメージの署名を検証します。

Helm でのインストール後、ClusterImagePolicy カスタムリソースでポリシーを定義します。

apiVersion: policy.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
  name: require-signed-images
spec:
  images:
    - glob: "ghcr.io/example/**"
  authorities:
    - keyless:
        url: https://fulcio.sigstore.dev
        identities:
          - issuer: https://token.actions.githubusercontent.com
            subjectRegExp: "^https://github.com/example/.*"

このポリシーを適用したネームスペースでは、ghcr.io/example/ 配下のイメージに対して署名検証が必須となります。検証に失敗した場合は Admission が拒否され、Pod は起動しません。Policy Controller v0.10 以降ではポリシーの段階的適用（mode: warn から mode: enforce への段階移行）がサポートされており、既存ワークロードへの影響を確認しながら移行できます。

なお、サードパーティのベースイメージ（例：nginx:alpine）にはそのままでは署名が付いていない場合があります。こうした外部イメージを使う際は、一度プライベートレジストリにコピーして自組織で署名し直す「ミラーリング＋再署名」のパターンが現場での標準的な対処法となっています。

2026年現在の環境差分と切り戻し時の注意点

Sigstore エコシステムは2024〜2026年にかけて大きく成熟しており、以前のドキュメントと現在の挙動が異なる箇所がいくつかあります。

まず、COSIGN_EXPERIMENTAL 環境変数は v2.4 以降では不要になりました。キーレス署名はデフォルトの動作として扱われます。旧バージョンのドキュメントを参照している場合は、この変数の有無で混乱が生じやすいため注意が必要です。

次に、Rekor の公開ログインスタンス（rekor.sigstore.dev）は現在も稼働中ですが、企業内では独自の Rekor インスタンスを立てて外部ログへの依存を排除する構成が増えています。Kubernetes クラスター向けには Sigstore の TUF（The Update Framework）ルート更新も重要で、cosign initialize コマンドによるルートメタデータの初期化を CI/CD パイプラインのセットアップ手順に含めておくと、証明書ルートの変更に追従できます。

また、OCI 1.1 規格への移行により、Cosign の署名ストア形式が oci.image.manifest.v1 に統一されつつあります。古い形式で署名されたアーティファクトとの混在が生じた場合、cosign triangulate コマンドで格納先の参照を確認してから検証すると、トラブルシューティングが容易です。

切り戻しの観点では、Policy Controller を導入した後に問題が発生した場合、Admission Webhook の failurePolicy を Ignore に設定することで一時的に検証をバイパスできます。ただしこれはあくまで緊急時の措置であり、問題解決後は速やかに Fail へ戻すことを徹底してください。署名ポリシーを無効化した状態でのデプロイは、導入前と同じリスクに戻ることを意味します。

コンテナイメージへの署名・検証は、CI/CDパイプラインの整備と合わせて導入することで初めて実効性を持ちます。手動検証スクリプトにとどまらず、Admission Webhook による強制適用まで一気通貫で設計することが、現代のサプライチェーンセキュリティ対策の現実的な基準となっています。