サプライチェーンの「聖域」を守れ：Cosignによるイメージ署名と検証の深層
コンテナイメージを `docker push` するだけで「デプロイ完了」と安堵しているのなら、あなたは既にサプライチェーン攻撃の格好の標的だ。
GitHub Actionsでビルドし、ECRやGCRに流し込む。このパイプラインのどこかに、権限昇格した攻撃者がバックドアを仕込んだイメージを差し替える余地はないか？ レジストリの認証情報を盗み出すことなど、彼らにとっては朝飯前だ。
今日語るのは、単なる「署名」の話ではない。イメージの真正性を担保し、ランタイムに至るまでの「信頼の連鎖（Chain of Trust）」をどう構築するかという、アーキテクトとしての防衛戦術だ。
—
1. なぜ「署名」だけでは不十分なのか
Notary (v1) が複雑すぎて普及に失敗した苦い歴史は、多くのエンジニアが知るところだろう。対して `Cosign` (Sigstoreプロジェクト) は、PKI管理の煩雑さを排除し、透明性の高い署名を実現した。
しかし、技術選定以上に重要なのは「検証ポリシー」の強制だ。
イメージに署名があることと、その署名が「誰によって、どのようなコンテキストで付与されたか」を検証することは全くの別次元の話である。
攻撃者の盲点：署名の「剥離」と「すり替え」
攻撃者はレジストリのメタデータに介入し、署名情報を消去したり、あるいは有効な署名を持つ別のイメージにタグだけを書き換えてすり替える。これを防ぐには、Kubernetes側のAdmission Controller（KyvernoやPolicy Controller）で、署名がないイメージや、信頼されていないキーで署名されたイメージを「即時拒否」する設定が不可欠だ。
—
2. 実装：Cosignによる署名と検証のアーキテクチャ
まずは、GitHub Actions等での署名プロセスと、Kubernetes側の防御層を構築するコードを見てほしい。
A. 署名フェーズ (GitHub Actions例)
キーレス署名（OIDCトークンを利用）を使うことで、長期的な秘密鍵管理の負債から解放される。
GitHub Actionsにおける署名プロセス
- name: Sign the image with Cosign
env:
COSIGN_EXPERIMENTAL: “true” # キーレス署名を有効化
run: |
# GitHubのIDトークンを利用して署名を生成
# これにより、CI環境に秘密鍵を配置する必要がなくなる
cosign sign –yes ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}@${{ steps.build.outputs.digest }}
B. 検証フェーズ (Kyverno Policy例)
Kubernetesクラスターに入ってくるイメージが、「特定のGitHub Org」によって署名されているかを確認するポリシーだ。
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: verify-image-signature
spec:
validationFailureAction: Enforce # 検証失敗時は即座にブロック
rules:
- name: check-signature
match:
resources:
kinds:
- Pod
verifyImages:
- imageReferences:
- “my-registry.com/app/”
attestors:
- entries:
- keys:
# 信頼する公開鍵のIDを指定
publicKeys: |-
—–BEGIN PUBLIC KEY—–
…
—–END PUBLIC KEY—–
—
3. 次世代の防衛：SBOMと署名の統合
署名は「誰が作ったか」を証明するが、「中に何が入っているか」までは証明しない。
昨今の攻撃トレンドは、OSパッケージの脆弱性を突くよりも、アプリケーションの依存ライブラリ（npm/pipパッケージ）に悪意あるコードを混入させる手法が主流だ。
ここでSBOM (Software Bill of Materials)の出番だ。
`cosign attest` を用いて、ビルド時に生成したSBOM（CycloneDX等）をイメージと紐付けて署名し、デプロイ時に「脆弱性スキャン結果を含まないイメージは実行させない」というガードレイルを敷く必要がある。
SBOMを生成し、イメージにアタッチして署名する
cosign attest –predicate sbom.json –type cyclonedx my-registry.com/app:latest
—
4. チーフホワイトハッカーの視点：限界と未来
どれだけ完璧な署名基盤を築こうとも、物理レイヤやカーネルへの攻撃手法が進化すれば、その信頼の連鎖は断ち切られる。
- 耐量子暗号への移行: 現在のRSA/ECDSA署名は、将来的な量子コンピュータの実用化により破られるリスクがある。Sigstoreが採用するEd25519などの署名アルゴリズムは比較的高耐性だが、アーキテクトはアルゴリズムの更新可能性を考慮した設計を常に維持せよ。
- プロンプトインジェクションとの交差点: LLMがコード生成を行う時代、その生成物（イメージ）が「AIによって汚染されていないこと」を証明する「AI署名」の概念が今後重要になる。コードの生成元が人間かAIか、そのガードレイルのログを署名に含める未来は遠くない。
結び：防御は「規律」である
セキュリティアーキテクチャの構築において、最も弱いのは「例外」を許容した瞬間だ。
「開発環境だから署名は不要」「急ぎのパッチだから検証をスキップ」——この妥協が、後の巨大なインシデントの引き金になる。
署名と検証は、もはや「導入すべき技術」ではなく、「開発という行為に組み込まれた言語」であるべきだ。自動化されたパイプラインの中に、冷徹なまでの検証プロセスを埋め込め。それが、真のプロフェッショナルがとるべき唯一の道だ。
コメント