【CNDW2025】コンテナイメージはどこで改竄されるのか、攻撃デモから学ぶビルド完全性とサプライチェーン防御

CloudNative Days Winter 2025で行われたセッション「改竄して学ぶコンテナサプライチェーンセキュリティ ～コンテナイメージの完全性を目指して～」は、株式会社NTTデータのSoftware Engineerである望月啓太氏によるもので、コンテナ活用が進む現代のシステムにおいて見落とされがちなビルドプロセス侵害のリスクに焦点を当てている。署名やSBOMといった従来の対策では防ぎきれないサプライチェーン攻撃の実態についてデモを交えて解説するとともに、in-totoやSLSAといった枠組みを通じて、コンテナイメージの完全性をどのように担保すべきか、その考え方と実践への道筋を示した。

ソフトウェアとコンテナのサプライチェーン全体を俯瞰する視点

近年、ソフトウェアサプライチェーンセキュリティへの関心が高まっている。ソフトウェアサプライチェーンとは、ソフトウェアの開発開始からビルド、配布、実行に至るまでの一連の流れを指し、その全体がセキュリティの対象となる。登壇したNTTデータの望月氏は「この流れを構成するあらゆる要素において、脅威が発生する可能性がある」と語り、個々の工程ではなく全体を俯瞰する視点の重要性を強調した。

この考え方をコンテナ環境に当てはめたものが、コンテナサプライチェーンである。ソースコードとDockerfileからコンテナイメージをビルドし、レジストリへアップロード、Kubernetes上で実行するという流れは、現在多くのクラウドネイティブ環境で一般的となっている。この過程では、従来のコンテナセキュリティ対策に加え、サプライチェーン全体を意識した対策が求められる。

代表的な手法として挙げられるのがSBOMとコンテナイメージへの署名である。SBOMはソフトウェアを構成する依存関係などを一覧化し、脆弱性検査やライセンス管理に活用される。一方、署名は開発者が生成した正当なイメージであることを検証する仕組みであり、レジストリ上での改竄や意図しないイメージの混入を防ぐ効果を持つ。

SBOM(Software Bill of Materials)

セッションでは、署名の実装を支えるツールとしてSigstoreプロジェクトのCosignが紹介された。Cosignはコンテナイメージなどのアーティファクトに対して署名と検証を行うオープンソースツールであり、OIDCを用いたキーレスサイニングにも対応している。望月氏は「鍵管理を意識せずに署名できる仕組みが用意されている」と述べ、署名が現実的な運用として組み込みやすくなっている点を示した。

しかしこれらの対策がカバーできるのは、あくまでビルド後や配布段階の信頼性に限られる。望月氏は「ここまでの対策では、ビルドが正しく実行されたかどうかまでは保証できません」と指摘し、コンテナサプライチェーンにおける盲点として、ビルドプロセスそのものの完全性に注目する必要性を提示した。次章では、この課題を可視化する攻撃デモが紹介される。

署名では防げないビルドプロセス侵害を示す攻撃デモ

セッションでは、コンテナサプライチェーンにおけるビルドプロセス侵害を理解するため、実際の攻撃を想定したデモが行われた。対象となったのは、Go言語で実装されたシンプルなWebアプリケーションである。ソースコードとDockerfileを基にコンテナイメージをビルドし、レジストリへアップロード、署名を付与したうえでKubernetesにデプロイするというサプライチェーンが再現された。

状況設定

デモではまず、コンテナイメージのビルドとレジストリへのプッシュ、Cosignによる署名、署名検証を経て、Kubernetes上にPodをデプロイするまでの一連の流れが実行された。ブラウザからアプリケーションにアクセスすると、実装通りのメッセージが表示され、手順上は何の問題もないように見える状態であった。

しかし特定のパスにアクセスすると、開発者が実装した覚えのない挙動が確認された。望月氏は「実はもう攻撃は終わっているんですよね」と語り、問題はデプロイ後ではなく、ビルドの時点で発生していたことを示した。調査の結果、ビルド環境そのものに悪意のあるプロセスが仕込まれており、コンテナイメージのビルド中にソースコードが改竄されていたことが明らかとなった。

この攻撃では、ビルドプロセスを監視し、特定のコマンド実行を検知するとソースコードを書き換える仕組みが用いられていた。その結果、改竄されたコードを含むコンテナイメージが正規の手順でビルドされ、署名も付与された状態でレジストリに登録されていた。署名や検証は正しく機能していたものの、「署名を行った時点で、すでに中身は改竄されていた」という状況である。

望月氏は、この構造が2020年に発生したSolarWinds事件と本質的に同じである点を指摘した。署名やスキャンといった従来の対策は、ビルド後の成果物の信頼性は担保できるが、ビルドプロセス自体が侵害された場合には無力となる。このデモは、コンテナサプライチェーンにおいて「ビルドの完全性」が未解決の課題であることを強く印象づけるものとなった。

in-totoとSLSAに学ぶビルド完全性確保の考え方

このようにビルドプロセス自体が侵害された場合、署名や脆弱性スキャンだけでは改竄を検知できない。この課題に対する代表的なアプローチとして、望月氏はin-totoとSLSAという二つのフレームワークを紹介した。いずれも、ビルドの完全性を担保することを目的としているが、その立ち位置と役割は異なっている。

in-totoは、ソフトウェアサプライチェーンの各ステップが「期待通りに実行されたか」を検証するためのフレームワークである。ビルドやテストといった工程ごとに実行証跡を記録し、それらを事前に定義したルールと照合することで、改竄の有無を検証する。具体的には、各ステップの入力や出力、実行コマンドなどを記録したLinkファイルと、全体の検証ルールを定義するLayoutファイルを用いる。望月氏は、in-totoが「サプライチェーンのどこで、何が実行されたのかを追跡できる点」に強みがある一方で、ビルド環境そのものが侵害されている場合には限界があることにも触れた。

in-totoの概要

一方、SLSAはサプライチェーンセキュリティを段階的に整理するための成熟度モデルである。Googleの取り組みを起点として策定されており、現在はビルドに関するトラックが中心となっている。SLSAでは、ビルド環境の隔離や、どのような入力からどのような成果物が生成されたのかを示すProvenanceの生成と検証が重要な要素とされる。SLSAのレベルは、これらがどの程度信頼できる形で実装されているかによって定義される。

SLSAの概要

in-totoとSLSAは競合するものではなく、補完関係にある。in-totoは個々のステップの実行証跡を詳細に扱う枠組みを提供し、SLSAはそれらを含めたビルドプロセス全体を評価するための指針を示す。望月氏は、GitHub Actionsを用いたSLSA準拠の実装例にも触れ、現実的な環境でも段階的にビルドの完全性を高めていくことが可能であると示した。

ビルドの完全性を起点に進化するコンテナサプライチェーン対策

セッションでは、コンテナサプライチェーンにおけるセキュリティ対策を、特にビルドプロセスの完全性という観点から整理した。SBOMやコンテナイメージへの署名は、サプライチェーンの可視化や配布段階の信頼性確保において重要な役割を果たす。一方で、ビルド環境そのものが侵害された場合には、これらの対策だけでは改竄を防げないことが、攻撃デモを通じて示された。

望月氏は、こうした課題に対するアプローチとして、サプライチェーンの完全性を検証するフレームワークであるin-totoと、ビルドプロセスの成熟度を定義するSLSAを紹介した。in-totoとSLSAは、それぞれ異なる立場からビルドの完全性にアプローチする枠組みである。

これらのフレームワークは、単独で万能な解決策となるものではない。望月氏は「ソフトウェアサプライチェーンセキュリティはまだ発展途上の分野です」と述べつつも、対応するツールや実装例が整いつつある現状に触れ、段階的に取り組むことの重要性を強調した。署名やスキャンに加え、ビルドの完全性という視点を取り入れることで、コンテナサプライチェーンのセキュリティは次の段階へ進む。そのための基礎知識として、本セッションで示された考え方は、今後の要件対応に備えるうえで有用な示唆を与えるものとなった。