出典: Siwakorn1933 via Shutterstock
コンテナ化技術はソフトウェア開発やクラウド展開を容易にしますが、このエコシステムの基盤となるイメージには不要なコンポーネントや数百もの脆弱性が含まれていることが一般的です。現在、複数のベンダーがこれらのイメージのクリーンアップとセキュリティ強化に取り組んでいます。
例えばChainguardの調査によると、人気のDebianベースのDockerイメージには平均で280件の脆弱性が含まれており、NetRiseが70種類のイメージを無作為に抽出して行った調査では、平均して1つのコンテナに604件の脆弱性が存在することが分かりました。
このような大量の脆弱性は、イメージの作成方法の副産物です。多くの場合、コンテナ化されたLinuxディストリビューションを基盤とし、他のソフトウェアを追加して作られます。目的は単に技術を動作させることだと、Dockerのプロダクト担当副社長Michael Donovan氏は語ります。
「過去10年以上にわたり、業界全体で多くのコンテナワークロードを支えてきたのは、実際には必要のないソフトウェアが多数含まれていたからです」とDonovan氏は言います。「ほとんどの開発者は、さまざまなシステムパッケージをすべて理解しているわけではありません……自分のアプリケーションが動けばいいのです。」
Dockerは、増加する脆弱性の問題を解決するために、開発者向けに強化イメージ（実質的に人気ソフトウェアスタックのスリム化バージョン）を提供する企業や団体の一つです。強化イメージには、開発者のニーズを満たすために必要最小限のコンポーネントのみが含まれており、既知またはほぼゼロの脆弱性しか存在しません。
5月に開始されたDocker Hardened Imagesサービスは、例えばPython、PostgreSQL、Redis、Tomcatなど240以上の人気プロジェクトをベースにした1,600以上のイメージを提供しています。別のプロバイダーであるChainguardは1,800以上のプロジェクト向けに強化イメージを作成しています。また、スタートアップのCleanStartは350以上のオープンソースプロジェクト向けの強化イメージを維持しています。通常、強化イメージは脆弱性数を97%以上削減し、既知の脆弱性やCVEがほぼゼロとなっています。
ロード中...
トレードオフ：セキュリティと利便性
これらのサービスを利用することで、企業は信頼できるソフトウェアスタック上でSBOM（ソフトウェア部品表）が検証されたソフトウェアを構築し、連邦情報処理標準（FIPS）などの政府基準に準拠できます。さらに、イメージは不要なコンポーネントの排除やソフトウェア問題の修正のために随時更新されます。
AIによって支援された開発者による新たなコンテナ化アプリケーションの急増に伴い、事前にセキュリティが確保され継続的に更新されるイメージを持つことで、企業はコンプライアンスを証明できるようになると、CleanStartのCEOであるNilesh Jain氏は述べています。同社は年末までに1,000件の強化イメージ提供を目指しています。
「エコシステムは検証可能なソフトウェアサプライチェーンへと移行しています。政府の義務やエンタープライズバイヤーはすでに署名付きで追跡可能なアーティファクトを求めています」と彼は言います。「強化イメージは間もなく、あらゆる本番システムのデフォルトの出発点となるでしょう。」
セキュリティ重視の保守により、開発者は強化イメージをビルドプロセスの安全な基盤として扱うことができるとJain氏は述べます。他のサービスと同様に、CleanStartもCVEをほぼゼロに抑えることを目指しており、強化プロセスによってコード量も60%から80%削減されています。
残念ながら、多くの開発チームは強化コンテナを維持・構築するための運用成熟度を持っていないと、Red HatのエンタープライズLinux担当シニアプリンシパルプロダクトマネージャーであるBen Breard氏は述べています。
「コンテナ分野で『ゼロCVE』を追い求める企業は、アプリケーションのテストやデプロイに関する自社のプロセスがボトルネックになっていることに気付きがちです」と彼は言います。「一般的に、継続的インテグレーション（CI）の導入はスムーズに進み普及していますが、継続的デプロイメント（CD）はそこまで進んでいません。」
エコシステムは強化イメージに注力すべき
企業への一貫したアドバイスは、新しいコンテナ化アプリケーションはすべて強化イメージを基盤とすべきだということです。開発プロセスがよりスリムなソフトウェアエコシステムに適応するまでに時間がかかるかもしれませんが、得られるセキュリティ上の利益は無視できません。
開発パイプラインも、最新の修正に追いつくために更新とデプロイを自動化する必要があります。また、サプライチェーンにも注意を払う必要があります。なぜなら、1つのコンポーネントの更新が下流のイメージに反映されないことがよくあるからですと、Red HatのBreard氏は述べています。
「上流で変更があっても、下流のコンテナがそれを取り込まなければ意味がありません」と彼は言います。「したがって、頻繁にアップデートを提供するイメージエコシステムに依存するだけでなく、これらのアップデートを一貫して—できれば継続的に—取り込む仕組みも必要です。」
Red Hatは一貫してアップデートを提供していますが、開発者はパッケージマネージャーがイメージを再構築するまでその変更に気付かないこともあると彼は述べています。
最終的には、強化イメージサービスが組織のクラウドインフラストラクチャ向けの現行パイプラインの多くを置き換える可能性があります。なぜなら、サービスプロバイダーが強化作業を代行してくれるからですと、DockerのDonovan氏は述べています。
「私たちは、多くのお客様がCIパイプラインを停止しているという話を聞きました。なぜなら、今や私たちがその作業を代行しているからです」と彼は言います。「私たちはイメージのビルドだけでなく、上流のCVEやパッチの監視、カスタマイズされたイメージの再構築と納品まで、標準の強化イメージと同様に対応しています。」
