【テクニカル・上級編】コンテナイメージの脆弱性スキャンと署名検証(Cosign) – ガバナンス・リスク管理 & 生成AIセキュリティ防御ガイド

コンテナの「信頼」をハックする：脆弱性スキャンとCosignによるサプライチェーン防衛の真実

多くの組織が「CI/CDで脆弱性スキャンを回しているから安全だ」と胸を張るが、現場の最前線にいる我々から見れば、それは「鍵のかかっていない玄関に、高価な防犯カメラを設置している」ようなものだ。

コンテナセキュリティの真髄は、スキャン結果の良し悪しではない。「そのイメージが、我々が意図したビルドプロセスを経たものであるか」という証明（Provenance）と、「実行時の改ざんをいかに物理的に不可能にするか」というアーキテクチャにある。

今日は、表面的なツール導入の話ではなく、攻撃者がどこを突き、防衛側がどこで踏みとどまるべきか、その「戦術的防衛」の核心を掘り下げる。

—

脆弱性スキャンの盲点：CVEの先にある「メモリの腐敗」

脆弱性スキャン（TrivyやGrypeなど）は重要だが、これらは既知のCVEデータベースとの照合に過ぎない。しかし、現実のインシデントでは、スキャンをすり抜ける「ゼロデイ」や、ライブラリの依存関係に潜む「サプライチェーン汚染」が常に牙を剥く。

特に注意すべきは、コンテナイメージを構築する際、OSのベースレイヤーで何を許容しているかだ。

根本的な視点: パッケージマネージャー経由でインストールされるバイナリは、メモリ安全性（Memory Safety）が保証されていないC/C++製が多い。パケット構造を解析すると、スタックバッファオーバーフローを誘発させるペイロードが、正規のトラフィックに紛れて到達するケースは後を絶たない。
対策: スキャン結果のスコアだけで安心せず、ランタイム保護（eBPFを用いたシステムコール監視）を併用せよ。特定のコンテナがexecveやsocketを異常な頻度で呼び出していないか。ここが最後の防衛線になる。

—

Cosignによる署名検証：サプライチェーンへの「封印」

脆弱性をスキャンした直後、イメージをレジストリにプッシュする。その瞬間、中間者攻撃（MitM）やレジストリの侵害によって、イメージが差し替えられる可能性はゼロではない。ここで登場するのが Cosign による署名検証だ。

Cosignは単なる署名ツールではない。鍵管理の複雑さを排除し、透明性ログ（Rekor）を活用して「いつ、誰が、何を署名したか」を不変的に記録するアーキテクチャだ。

実践：CI/CDパイプラインへの統合ロジック

以下は、GitHub Actions等のパイプラインで、ビルド後にイメージへ署名を行う際の典型的なフローだ。

# 1. 秘密鍵を生成（KMSを利用することを強く推奨。ローカル管理は厳禁）
# cosign generate-key-pair

# 2. イメージに署名を行う（GitHub Actions等ではOIDCトークンを活用し、鍵管理を不要にする）
# cosign sign --key cosign.key <イメージタグ>

# 3. 署名の検証（これをKubernetesのAdmission Controllerで強制する）
cosign verify --key cosign.pub <イメージタグ> \
  --output text # 署名メタデータを標準出力して監査ログに残す

Kubernetes側では、Kyverno や Policy Controller を用いて、cosign verify に失敗したコンテナの実行を即座に拒否（Deny）するように設定する。これが「信頼できるソース以外は物理的に起動できない」という強固な防御層を構築する。

—

生成AIとガードレイル：プロンプトインジェクションへの防御

最近のトレンドとして、コンテナ内部でLLMを動かす構成が増えている。しかし、LLMをコンテナに積むことは、新たな攻撃対象領域（Attack Surface）を広げることに他ならない。

ユーザーの入力がそのままシステムプロンプトとして解釈される脆弱性は、もはや「SQLインジェクション」の現代版だ。コンテナセキュリティの文脈では、この防御を「アプリケーション層」ではなく「アーキテクチャ層」で実装する必要がある。

ガードレイル・アーキテクチャの指針

1. セグメンテーション: LLMを実行するコンテナには、いかなる外部ネットワーク接続も許可しない（Egressポリシーの厳格化）。
2. サンドボックス化: プロンプト評価（ガードレイル）を行うミドルウェアをサイドカーとして配置し、入力・出力の両方をシリアライズして検証する。
3. 署名されたモデルの利用: モデルのウェイトファイル自体に署名を行い、読み込み時に整合性を検証する。改ざんされたモデルは、いとも簡単に悪意ある回答を生成するからだ。

—

監査の観点：技術からガバナンスへ

チーフホワイトハッカーとして最後に伝えたいのは、「自動化されたプロセスこそが、最大の監査証跡である」ということだ。

コンテナイメージの署名検証ログは、単なる運用の記録ではない。それは「我々のサプライチェーンは健全である」ということを、数式（暗号学）によって証明する最強のガバナンス文書だ。

脆弱性スキャンのレポートを月次で出すのではなく、「署名のないイメージのデプロイ試行回数」と「検知された拒否ログ」を経営層に報告せよ。
これこそが、技術的な防御とビジネスリスク管理を直結させる、真のセキュリティアーキテクトの仕事である。

技術を磨け。ツールを疑え。そして、システムが「動くこと」ではなく「正しく動くこと」を、暗号とプロトコルの力で担保せよ。それが我々の責務だ。