コンテナイメージのセキュリティをソースで管理する

by Canonical on 12 August 2025

ソフトウェアサプライチェーンのセキュリティは、開発者やDevOpsエンジニア、さらにはIT責任者にとって最大の関心事です。セキュリティ侵害や依存ファイル侵害の大事件からわかるように、適切な検証と保守のないオープンソースコンポーネントはリスクの源となります。近年の開発とデプロイではコンテナ化が一般的な手法ですが、再現性とセキュリティの面に弱点があります。

コンテナには、簡単に導入できるだけでなく、安全で繰り返し使用でき、長期的なメンテナンスで新たな脅威に対応することが求められています。このことからCanonicalはコンテナ構築サービスの提供を開始しました。

オープンソースが抱えるセキュリティの課題

企業環境では、オープンソースソフトウェア(OSS)の利用が広がっています。各種の分析によれば、OSSは使用されているソフトウェア全体の約70%を占め、もはや補助的な要素というより、現代のアプリケーションの基盤です。さらに商用コードベースの97%に何らかのOSSが組み込まれていることも、OSSの重要性を裏付けています。ただし、OSSの利用拡大に伴い、オープンソースの脆弱性も多く見つかっています。調査によると、コードベースの84%に1つ以上の既知のオープンソースの脆弱性が含まれており、そのうちのほぼ半数が「重大」な脆弱性に分類されています。Black Duckの2025オープンソースセキュリティ&リスク分析(OSSRA)レポートによると、アプリケーションで使用されるオープンソースファイルの数は、2020年は平均で5,300ファイル、2024年には16,000ファイル以上と、わずか4年で3倍に増加しており、リスクが増大するのも当然と言えます。このような攻撃対象領域の拡大は、リスクの増大と直接的に相関しています。

CanonicalとIDCのレポートによると、組織がOSSを採用する主な理由は、コストの削減(44%)、開発の加速(36%)、信頼性の向上(31%)です。組織の90%が、OSの公式や信頼できるリポジトリからパッケージを入手したいと考えているにもかかわらず、大半は依然としてアップストリームのレジストリを利用しています。つまり、ITチームがパッチ適用の大きな責任を負うことになります。このレポートによれば、10チーム中7チームが1週間に6時間以上(ほぼ1日)をセキュリティ更新の入手と適用に費やしています。重大度の高い脆弱性には24時間以内にパッチを適用することを義務付けている組織も70%にのぼりますが、これを遵守できる自信があると回答したのはわずか41%です。さらに興味深いのは、半数以上の組織が運用中のシステムやアプリケーションを最新バージョンに自動的にアップグレードしておらず、既知の脆弱性にさらしているという点です。

サプライチェーン攻撃も発生頻度が増加しています。Sonatypeの調査によれば、ソフトウェアサプライチェーン攻撃の件数が2024年だけで倍増しています。また、Blackberryの調査では、75%以上の組織が、前年にサプライチェーン関連の攻撃を経験しています。Sonatypeの調査では、悪意のあるパッケージが過去12か月で急増しています。公開リポジトリでは50万件以上の不正パッケージが見つかり、前年比156%の増加となっています。このことから、攻撃者はアップストリームのオープンソースを標的として、ダウンストリームのユーザーを侵害していることがわかります。

このようなトレンドを踏まえ、開発チームはコンテナイメージの完全性を確保する方法を模索しています。再現可能なビルドや署名済みのイメージといった改ざん防止策のほか、イメージを最小限に抑えて脆弱性を減らす手もあります。ただし、このような対策を導入するには、多大な労力と専門知識が必要です。そこで威力を発揮するのが、Canonicalの最新ソリューションです。

Canonicalのコンテナ構築サービス

再現可能、堅牢、セキュリティメンテナンス付きのイメージ

これまでに挙げた課題に正面から取り組むため、Canonicalは新しいコンテナ構築サービスをリリースしました。このサービスでは、Canonicalのエンジニアが、セキュリティと長期運用を最優先として、あらゆるオープンソースプロジェクトまたはスタック向けにコンテナイメージをカスタムビルドします。オープンソースアプリケーションか、アプリのすべての依存ファイルを含むカスタムベースイメージかを問わず、Canonicalはお客様の仕様に従ってコンテナ化し、実運用向けにイメージを強化します。作成されたコンテナイメージはオープンコンテナイニシアチブ(OCI)形式で提供され、最長12年間のセキュリティメンテナンスが付属します。

コンテナ全体に対し最長12年間のサポート

コンテナ内のすべてのパッケージとライブラリ(Ubuntuのリポジトリに元々含まれていなかったものも含む)は、Canonicalのセキュリティ保守契約の対象となります。Canonicalは、重大な脆弱性に対して平均24時間以内にパッチを適用してきた実績があり、新たな脅威に対しても確実に迅速な対応を行います。OSコンポーネントのみをカバーする標準的なベースイメージとは異なり、Canonicalのサービスでは、コンテナビルドに必要なすべてのアップストリームのオープンソースコンポーネントが対象となります。つまり、たとえその一部がUbuntuにパッケージ化されていなかったとしても、オープンソースの依存関係ツリー全体が安全に保たれるということです。Canonicalは、定評のあるUbuntuの長期サポートをそのような部分にまで拡大するため、最新のフレームワーク、AI/MLライブラリ、ニッチなユーティリティなどを安心して使用できます。

各コンテナのイメージビルドには、最長12年間のセキュリティ更新期間が保証されています。これは、コミュニティのコンテナイメージの一般的なサポート期間をはるかに上回ります。これにより、規制の厳しい、あるいは長期運用が必要な業界でも、継続的にパッチを適用しながら10年以上にわたってコンテナを運用できます。

優れた移植可能性

堅牢化されたイメージは、あらゆる一般的なLinuxホストまたはKubernetesプラットフォームで実行できます。Ubuntu、RHEL、VMware、パブリッククラウドのKubernetesサービスなど、Canonicalはインフラストラクチャを問わず、このようなイメージを各プラットフォームでサポートします。こうした幅広い互換性により、必ずしもホスト上でUbuntuを実行している必要はありません。コンテナイメージは高い移植可能性を備え、Canonicalによってあらゆる環境でサポートされます。

長期的な再現性と自動化

Canonicalのビルドパイプラインは、再現性と自動化を重視しています。コンテナイメージの設計と構築が完了した後は、自動化されたパイプライがイメージを継続的にリビルドし、最新のセキュリティパッチを適用します。これによりイメージは手動での介入なしに最新の状態に保たれます。再現可能なビルドプロセス(Canonicalによる検証が可能)により、実運用環境で実行するイメージは、検証済みのソースコードおよびバイナリと常に正確に一致します。

つまり、新しいコンテナ構築サービスとは、Ubuntuの専門家が、お客様のアプリケーションに合わせ、安全性、再現性、信頼性を備えたコンテナイメージを提供するということです。コンテナのセキュリティメンテナンスという負荷の高い作業をCanonicalに任せることで、コンテナイメージの脆弱性に常に対応する必要がなくなり、コードの作成と機能のデプロイに集中できます。

最小限のフットプリント、最適なパフォーマンス

Canonicalの際立つアプローチは、Chiselで生成したUbuntuコンテナイメージを使用することです。Chiselイメージは、Canonicalの「ディストリビューションレス」コンテナのコンセプトに基づき、アプリケーションの必須ランタイムコンポーネントのみを含む超小型のイメージです。不要なパッケージ、ユーティリティ、メタデータを取り除くことで、Chiselイメージはイメージサイズと攻撃対象領域を大幅に縮小します。

Chiselイメージとは、Chiselと呼ばれるオープンソースのツールを使って生成し、アプリケーションに必要最低限の要素だけを含むイメージです。Chiselで生成したUbuntuコンテナイメージは、Ubuntuをベースにしながらも、余分なコンポーネントはまったくありません。

Chiselイメージは、アプリケーションの実行に必須のファイルとライブラリのみを含み、余分なディストリビューションメタデータ、シェル、パッケージマネージャ、実運用環境で不要なツールは除外しています。このためChiselイメージは一般的なUbuntuイメージよりも大幅に小型です。これにより、ストレージ容量が減り、転送速度が上がるだけでなく、脆弱性が潜む可能性も減少します。MicrosoftのACAチームが行った.NETコンテナ最適化の検証では、ChiselによってバックエンドAPIイメージのサイズが226 MBから119 MBに縮小しました(56.6%の削減)。また、CVEも25件から2件と92%も減少しました。パッケージ数も451個から328個に減り、脆弱性を含むリスクが減少しています。

無駄のないChiselコンテナは高速に起動し、メモリ使用量も削減されます。必須コンポーネントしかないため、イメージのプルとコンテナの起動が高速です。たとえば、.NETのランタイムイメージをChiselで生成すれば公式のイメージから約100 MBを削減し、自己完結型アプリ用のわずか6 MB(圧縮済み)のランタイムベースが実現します。このような小さなフットプリントは、ネットワーク転送の高速化とメモリオーバーヘッドの低減につながります。

Chiselで生成したUbuntuイメージをコンテナの構築に使用することで、世界中の開発者に愛用されるLinuxディストリビューションをベースとしながら、各コンテナを可能な限り小さくロックダウンできます。つまりこれを使用するだけでセキュリティも強化されるのです。また、Ubuntuをベースとするイメージのため、Ubuntuの長期サポートポリシーも適用されます。CanonicalのコンテナイメージはUbuntu LTSのリリースサイクルに準拠しており、コアコンポーネントに対して5年間のセキュリティアップデートが無償で提供されます(Ubuntu Proでは10年間に延長されます)。新しいコンテナ構築サービスでは、企業ユーザーに12年間のサポートが提供され、最小限のランタイムコンポーネントにCVEに対するパッチが長期的に適用されます。

Ubuntu Proをベースとした構築

Canonicalが「長期サポート(LTS:Long Term Support)」という用語を生み出したのは、2006年のUbuntu 6.06 LTSまで遡ります。これにより、5年間の更新を保証する安定したOSリリースという概念を確立しました。それ以来、Ubuntu LTSは企業における信頼性の代名詞です。これをさらに強化した製品が、2019年に発表したUbuntu Proです。Ubuntu Proは、Ubuntuのコアシステムだけでなく、数千ものコミュニティ(Universe)パッケージにも包括的なセキュリティメンテナンスを提供し、FIPS 140認証の暗号化など、エンタープライズ機能も備えています。現在のUbuntu Proは、36,000以上のパッケージに10年間のメンテナンスを提供する包括的なオープンソースセキュリティ製品です。

新しいコンテナ構築サービスは基本的にンテナイメージ向けのUbuntu Proのため、この背景は大きな意味があります。Canonicalは、自動パッチ適用、脆弱性の修正、および長期メンテナンスの専門知識をコンテナ内のフルスタックにまで拡大しています。つまりCanonicalにコンテナイメージの設計と保守を依頼すれば、ソフトウェアサプライチェーンを監視する専任チームを得たも同然です。コンテナに含まれるすべてのアップストリームプロジェクトは、セキュリティの問題がないか継続的に監視されます。スタックの任意のレイヤー(OS、共有ライブラリ、あまり普及していないPythonパッケージなど)で新しい脆弱性が出現した場合、Canonicalは事前にパッチを適用し、自動化されたパイプラインを通じて更新されたイメージを発行します。これらはすべて主にバックグラウンドで処理されますが、コンプライアンス遵守のために必要であれば、通知を受け取ったり、更新を追跡したりできます。このようなディリジェンスを社内で行うとすれば大きなコストと手間がかかるでしょう。

さらにCanonicalが関与することで、自社構築のイメージでは困難な、管理と信頼の連鎖が実現します。コンテナは、Ubuntuの公式リリースと同じインフラストラクチャを使用して、Canonicalが構築および署名するため、完全性が確保されます。Canonicalとそのパートナーは、重要な資産についてゼロ距離のサプライチェーンを構築しました。つまり、ソースコードから最終的なコンテナアーティファクトに至るまで、緊密な統合と検証が行われます。このアプローチにより、サプライチェーンにおける改ざんやマルウェアの潜入リスクが大幅に軽減されます。

Ubuntuは幅広い信頼を得ているため、Canonicalのコンテナイメージは、非常に規制の厳しい環境での使用が事前に承認されています。特に、強化されたUbuntuコンテナイメージは、米国国防総省の「Iron Bank」リポジトリ(政府機関向けの強化コンテナのコレクション)ですでに認証を受けており、利用可能です。つまりCanonicalのサービスを利用することで、このレベルの信頼性とコンプライアンスを確保できるのです。ベースイメージとコンポーネントがUbuntu Proのセキュリティレジームによってサポートされ、監査可能なメンテナンスの証拠を提供できるため、FedRAMPやDISA-STIGのほか、今後施行される欧州サイバーレジリエンス法などの基準への準拠が容易になります。

コンテナ構築サービスとは、Ubuntu ProとオープンソースセキュリティにおけるCanonicalの長年の経験に基づくサービスです。カスタムコンテナは、単なるオーダーメイドのイメージではありません。明確なメンテナンス契約とセキュリティSLAを含むエンタープライズグレードのアーチファクトであり、監査担当者やITガバナンスチームにとって高い価値があります。

Canonicalのコンテナ構築サービスは、OSからアプリの依存ファイルに至るまで、コンテナスタックのすべてのレイヤーを対象としたメンテナンスの提供を目的としています。最適化され、Chiselによってサイズが縮小されているだけでなく、10年間にわたるアップデートとCanonicalのサポートが提供される、実運用環境向けに構築されたイメージです。

Canonicalのコンテナ構築サービスの詳細 >

コンテナスタックの保護については、こちらからお問い合わせください >

ニュースレターのサインアップ

Ubuntuニュースレターの配信登録

お客様が購読登録を行われる場合、以下の条件に同意されたことになります。Canonicalのプライバシーに関するお知らせ個人情報保護ポリシー

関連記事

OpenJRE 8、17、21に対応するChisel生成のUbuntuコンテナ

Canonicalは、OpenJDKプロジェクトが提供するOpenJRE 8、17、21(Open Java Runtime Environment)に対応したChiselコンテナを発表しました。これらのコンテナイメージはサイズとセキュリティを重視し、必要不可欠な依存ファイルのみを含みます。AMD64とARM64の両アーキテクチャに対応しており、12年間のセキュリティサポートが付属します。 イメージは、以下のリンクからダウンロードできます。 Canonicalは、Chiselで生成したUbuntuコンテナを同等のJREイメージと比較するため、一連のベンチマーク測定を実施しました。GitHubリポジトリへのリンクは、このページの下部に記載されています。 Chisel生成のJ […]

CanonicalのOpenJDKビルドの概要

Javaは長年にわたり、大企業におけるソフトウェア開発で最も多く使われてきた言語であり、特に金融、医療、行政などの業界では、Fortune 500企業の90%がバックエンド開発にJavaを使用しています。 Javaの開発者は、他の開発者に比べ、新しい機能の導入と、レガシーアプリケーションのセキュリティ、安定性、パフォーマンスの両立に苦労します。Javaの各種バージョン、セキュリティ更新、そしてデプロイメントアーティファクトの管理は、かなり複雑です。 このためCanonicalはツールチェーンに大きく投資し、企業にもコミュニティメンバーにもメリットのある包括的なサービスを提供することにしました。CanonicalのOpenJDKサポートは、以下の基本方針に基づいて提供されて […]

BroadcomとCanonical、VMware Cloud FoundationをAI・コンテナ向けに最適化

大手クラウドOSと業界初の統一プライベートクラウドプラットフォームを組み合わせ、クラウドネイティブ化を推進 Broadcom(NASDAQ:AVGO)とCanonicalは、両社の技術を利用する企業が現代のコンテナベースのアプリケーションやAIアプリケーションをより短時間で安全に出荷できるよう、提携を拡大すると発表しました。このパートナーシップでは、Canonicalの信頼性高いオープンソースソフトウェアと、業界初の統一プライベートクラウドプラットフォームを組み合わせることで、利用企業による低コスト、低リスクの革新を推進します。 BroadcomのVMware Cloud Foundation部門製品担当バイスプレジデントであるPaul Turner氏は、次のように述べて […]