セキュリティ19分で読める

Kubernetesサプライチェーン攻撃が激化——コンテナイメージ改ざんとSigstoreによる防御

セキュリティクラウド開発ツールオープンソース
加木谷 直俊ソース記事を見る

Kubernetesクラスタで稼働するコンテナイメージの約40%に既知の高深刻度脆弱性が含まれている——。Sysdig 2026 Cloud Native Security Reportのこの衝撃的なデータが示すのは、コンテナ化されたワークロードのサプライチェーンが、いまや攻撃者にとって最も魅力的な侵入経路のひとつになっているという現実だ。

2026年に入ってから、AIワークロードを標的とする新型マルウェア「VoidLink」の発見、Ingress-NginxのCVSSスコア9.8という致命的な脆弱性の公開、そして人気Helmチャートリポジトリへの悪意あるバージョン混入と、Kubernetesサプライチェーンを狙った攻撃が立て続けに発生している。CNCF（Cloud Native Computing Foundation）の調査によると、本番環境でKubernetesを利用する組織の96%がサプライチェーンセキュリティを「最優先課題」と回答しており、その対策の中核として注目されているのがSigstoreプロジェクトによるコンテナイメージ署名・検証だ。

この記事では、2026年に激化するKubernetesサプライチェーン攻撃の実態を解剖し、Sigstore/cosignを中心とした防御戦略、そしてSLSAフレームワークに基づくソフトウェアサプライチェーン保護の実践的な導入ガイドを提供する。

Kubernetesサプライチェーン攻撃とは何か

Kubernetesサプライチェーン攻撃とは、コンテナイメージのビルド・配布・デプロイの各段階で悪意あるコードやコンポーネントを混入させる攻撃手法の総称だ。従来のWebアプリケーション攻撃がランタイムの脆弱性を突くのに対し、サプライチェーン攻撃はソフトウェアの信頼の連鎖（Chain of Trust）そのものを破壊する。

攻撃の影響範囲が桁違いに大きいのが特徴だ。ひとつの汚染されたベースイメージが、数千のダウンストリームイメージに波及し、最終的に数万のKubernetesクラスタに影響を及ぼす。2021年のSolarWinds事件がソフトウェアサプライチェーン攻撃の脅威を世界に知らしめたが、コンテナエコシステムではその攻撃対象面（Attack Surface）がさらに広い。

以下の図は、Kubernetesサプライチェーン攻撃が発生しうる各段階と、2026年に確認された主要な攻撃事例を示しています。

Kubernetesサプライチェーン攻撃の全体像。ソースコードからCI/CDビルド、レジストリ、Helmチャート、K8sクラスタまでの各段階における攻撃ベクトルと、VoidLink・Ingress-Nginx脆弱性・Helmチャート汚染の実例

この図が示すように、攻撃者はサプライチェーンのあらゆる段階を狙う。特に2026年は、コンテナレジストリのイメージ改ざんとHelmチャート汚染が急増しており、従来のランタイムセキュリティだけでは防ぎきれない状況となっている。

2026年の主要攻撃事例

VoidLink——AIワークロードを標的とする新型マルウェア

2026年2月にセキュリティ研究者によって発見された「VoidLink」は、コンテナオーケストレーション環境で稼働するAIワークロードを特異的に標的とするマルウェアだ。正規のPythonパッケージに偽装してコンテナイメージに混入し、GPU メモリに直接アクセスしてLLM（大規模言語モデル）の重みデータや推論リクエストのデータを窃取する。

VoidLinkの巧妙さは、通常のコンテナセキュリティスキャンでは検出が極めて困難な点にある。マルウェア本体は暗号化されたペイロードとして配布され、コンテナ起動後にGPUドライバーのカーネルモジュール経由で展開される。既存のCVEデータベースに該当する脆弱性が存在しないため、シグネチャベースのスキャナでは検知できない。

Ingress-Nginxの重大脆弱性（CVE-2026-XXXX）

2026年3月に公開されたIngress-Nginxの脆弱性は、CVSSスコア9.8（Critical）と評価された。認証なしでリモートコード実行（RCE）が可能であり、Kubernetes環境のIngress Controllerを乗っ取ることで、クラスタ全体のトラフィックを傍受・改ざんできる。

この脆弱性の影響範囲は甚大で、Ingress-NginxはKubernetes環境で最も広く使われているIngressコントローラーのひとつだ。CNCFの統計では、本番Kubernetesクラスタの約**40%**がIngress-Nginxを使用しており、パッチ適用前の窓口期間に複数の攻撃が確認されている。

Helmチャートリポジトリ汚染

2026年1月、人気のサードパーティHelmチャートリポジトリで、正規バージョンに偽装した悪意あるチャートが発見された。攻撃者はチャートのバージョン番号を微妙に変更（例: 1.2.3 → 1.2.4）し、インストール時にクリプトマイナーとバックドアを仕込むinitContainerを追加していた。この攻撃は発覚まで約3週間にわたり、推定数千のクラスタに影響を及ぼした。

コンテナイメージ署名の仕組み——Sigstoreとcosign

これらの攻撃に対する根本的な防御策が、コンテナイメージの暗号署名と検証だ。その中核を担うのが、Linux Foundationが支援するオープンソースプロジェクトSigstoreである。

Sigstoreの3つのコアコンポーネント

Sigstoreは以下の3つのコンポーネントで構成される。

  • cosign: コンテナイメージに暗号署名を付与し、検証するCLIツール。OCI（Open Container Initiative）規格に準拠しており、既存のコンテナレジストリとの互換性が高い
  • Fulcio: OIDC（OpenID Connect）認証に基づく短期証明書を発行する認証局（CA）。証明書の有効期間はわずか20分で、長期的な鍵管理の負担を大幅に軽減する
  • Rekor: 署名の記録を改ざん不可能な透過ログ（Transparency Log）に保存する。Certificate Transparencyと同様の設計で、すべての署名操作が公開検証可能

署名・検証のワークフロー

以下の図は、Sigstore/cosignを使ったコンテナイメージの署名と検証のフロー、およびSLSAフレームワークとの関係を示しています。

Sigstore/cosignによるコンテナイメージ署名・検証フロー。ビルド時にcosignで署名し、FulcioがOIDC認証で短期証明書を発行、Rekorが透過ログに記録。デプロイ時にAdmission Controllerがcosign verifyで検証し、検証OKならデプロイ許可、NGならデプロイ拒否する

この図が示すように、Sigstoreの署名・検証フローは「ゼロトラスト」の原則をサプライチェーンに適用したものだ。ビルドパイプラインで署名されたイメージのみがKubernetesクラスタにデプロイされ、未署名または署名が無効なイメージはAdmission Controllerの段階で自動的に拒否される。

実際のcosignコマンドは非常にシンプルだ。

# イメージへの署名（キーレスモード）
cosign sign --yes ghcr.io/myorg/myapp@sha256:abc123...

# イメージの署名検証
cosign verify \
  --certificate-identity=build@myorg.iam.gserviceaccount.com \
  --certificate-oidc-issuer=https://accounts.google.com \
  ghcr.io/myorg/myapp@sha256:abc123...

SLSAフレームワーク——サプライチェーン完全性の基準

Sigstoreによるイメージ署名をさらに体系化するのが、Googleが提唱するSLSA（Supply-chain Levels for Software Artifacts）フレームワークだ。SLSAは4つのレベルでソフトウェアサプライチェーンの成熟度を定義する。

SLSAレベル要件防御範囲実装難易度
L1ビルドプロセスの文書化・来歴（Provenance）の記録ビルドの追跡可能性を確保低
L2ホストされたビルドサービスの使用（GitHub Actions等）ビルド環境の改ざんを防止中
L3ビルド環境の分離・改ざん耐性の確保内部脅威からの保護高
L4すべての依存関係の完全な検証・二者レビューサプライチェーン全体の保護非常に高

2026年3月時点で、GitHub ActionsはSLSA L3のビルド来歴（Build Provenance）を自動生成する機能を提供しており、cosignとの連携でイメージ署名にSLSA準拠のアテステーション（証明書）を添付できる。

主要ツール比較——どの署名・検証ソリューションを選ぶか

コンテナイメージの署名・検証ツールは複数存在する。主要なソリューションを比較する。

ツール提供元キーレス署名透過ログK8s統合OSSライセンス導入実績
Sigstore/cosignLinux Foundation○○（Rekor）○Apache 2.0Kubernetes, npm, PyPI
Notation (Notary v2)CNCF/Microsoft○×○Apache 2.0Azure Container Registry
Docker Content TrustDocker××△Apache 2.0Docker Hub
ConnaisseurSecuresign××○Apache 2.0中小規模クラスタ

現時点で最も推奨されるのはSigstore/cosignだ。キーレス署名（Keyless Signing）により、開発者が秘密鍵を管理する負担を完全に排除しつつ、Rekorの透過ログで署名の完全な監査証跡を残せる。2026年にはKubernetesのリリースイメージ自体がcosignで署名されており、エコシステム全体の標準ツールとなっている。

Docker環境でもcosignはシームレスに動作し、Docker公式のBuild Cloudとの統合が2026年初頭にGA（一般提供）となった。

Kubernetes Admission Controllerによる強制検証

署名されたイメージの検証を自動化し、ポリシーとして強制するには、KubernetesのAdmission Controllerを活用する。主要な選択肢は以下の通りだ。

Kyverno

CNCFのGraduatedプロジェクトであるKyvernoは、YAMLベースのポリシーでイメージ署名検証を定義できる。cosignとの統合が最も成熟しており、以下のようなポリシーで未署名イメージのデプロイを完全にブロックできる。

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signature
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-cosign-signature
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - imageReferences:
            - "ghcr.io/myorg/*"
          attestors:
            - entries:
                - keyless:
                    subject: "build@myorg.iam.gserviceaccount.com"
                    issuer: "https://accounts.google.com"
                    rekor:
                      url: https://rekor.sigstore.dev

OPA/Gatekeeper

より汎用的なポリシーエンジンとしてOPA（Open Policy Agent）/Gatekeeperも選択肢になる。Regoで柔軟なポリシーを記述できる反面、cosignとの統合にはカスタム実装が必要で、学習コストが高い。

導入時のポイント

Admission Controllerの導入は段階的に行うべきだ。まず Audit モードで未署名イメージの利用状況を可視化し、十分なカバレッジが確認できた段階で Enforce モードに切り替える。一気に強制モードにすると、署名されていないサードパーティイメージのデプロイがブロックされ、本番障害を引き起こすリスクがある。

料金体系

Sigstoreのコアコンポーネント（cosign、Fulcio、Rekor）はすべて無料のオープンソースだ。パブリックインスタンス（rekor.sigstore.dev、fulcio.sigstore.dev）も無料で利用できる。

ただし、エンタープライズ環境でプライベートインスタンスを運用する場合は、インフラコストが発生する。

項目パブリック（無料）プライベート（自社運用）マネージドサービス
Fulcio/Rekorsigstore.dev自社K8sクラスタChainguard Enforce等
月額コスト無料約$500〜$2,000（約75,000〜300,000円）約$5,000〜（約750,000円〜）
SLAベストエフォート自社責任99.9%以上
監査ログ公開ログ非公開可専用ダッシュボード

Chainguard Enforceは、Sigstoreの商用マネージドサービスとして最も導入実績が多い。プライベートRekorインスタンスの運用、SBOMの自動生成、脆弱性の継続的モニタリングをワンストップで提供する。

日本企業への影響と導入の必然性

規制対応の加速

日本においても、サプライチェーンセキュリティへの規制圧力は急速に高まっている。経済産業省の「サイバーセキュリティ経営ガイドライン v3.0」ではサプライチェーンリスク管理が重要10項目のひとつとして明記されており、2026年にはNISC（内閣サイバーセキュリティセンター）が政府機関向けにソフトウェアBOM（Software Bill of Materials）の義務化を検討している。

米国のSLSAフレームワークやEUのCyber Resilience Act（CRA）といったグローバル規制への準拠も、日本の輸出企業にとっては避けて通れない。特にCRAは2027年の完全施行を控えており、EU市場にソフトウェアを出荷するすべての企業にSBOMの提出とサプライチェーンの透明性確保を義務付ける。

日本のKubernetes導入状況

IDC Japanの調査によると、日本の大企業のKubernetes導入率は2026年時点で**約45%に達しており、前年比12ポイントの増加だ。しかし、コンテナイメージの署名・検証を本番環境で実施している企業はわずか8%**にとどまる。この「導入率と対策率のギャップ」は、日本企業が攻撃者にとって格好のターゲットとなるリスクを示唆している。

メガバンク、通信キャリア、製造業のIoTプラットフォームなど、ミッションクリティカルなワークロードをKubernetesで運用するケースが増えるなか、サプライチェーンセキュリティの未整備は経営リスクそのものだ。

日本語リソースの不足

Sigstoreの公式ドキュメントは英語のみであり、日本語の実践的なガイドは極めて少ない。CNCFジャパンチャプターが2026年からSigstoreハンズオンを定期開催しているが、企業の導入を加速するには、SIer各社によるマネージドサービスの充実が急務だ。

まとめ——いますぐ始める3つのアクション

Kubernetesサプライチェーン攻撃は、2026年において「起きるかどうか」ではなく「いつ自社に影響するか」の問題だ。VoidLinkのようなAIワークロード標的型マルウェアの登場は、攻撃の高度化と標的の拡大を如実に示している。

以下の3ステップで、いますぐ防御を開始できる。

  1. cosignによるイメージ署名の導入（1〜2日）: CI/CDパイプラインにcosignのキーレス署名を組み込む。GitHub ActionsならSigstoreの公式Actionで数行の追加で実現できる。まずは社内で最もクリティカルなイメージから着手する

  2. Admission Controllerの設定（1〜2週間）: KyvernoをAuditモードで導入し、クラスタ内で使われている未署名イメージの棚卸しを行う。可視化が完了したら、段階的にEnforceモードへ移行する

  3. SLSAフレームワークへのロードマップ策定（1ヶ月）: 現状のビルドパイプラインをSLSAレベルで評価し、L2（ホストされたビルド）→ L3（改ざん耐性）への段階的な改善計画を策定する。SBOMの自動生成も並行して導入し、EUのCRA施行に備える

コンテナイメージの署名は、鍵管理の煩雑さがかつての導入障壁だった。Sigstoreのキーレス署名がその障壁を取り除いたいま、導入しない理由はもはやない。サプライチェーンの「信頼の連鎖」を暗号的に保証する——それが2026年のKubernetesセキュリティの最低基準だ。

この記事をシェア

XはてブLinkedIn

「セキュリティ」カテゴリの記事

「セキュリティ」の記事をもっと見る

関連記事

新着記事