Kubernetesがコンテナ戦争を制したことは、誰もが知っています。ただし、Kubernetesが制したのはコンテナランタイムをめぐる戦いです。一方、コンテナイメージをめぐる戦いを制したのはDockerです。そのことは、State of Open Source Security Report 2019によると、2週間ごとに10億を超えるDockerコンテナがダウンロードされているという統計からも分かります。Docker Hubは企業にとって、消費者にとってのAppleのAppStoreやGoogle Playのような存在になっています。
コンテナイメージは、基本オペレーティングシステムからアプリケーションスタック、データベース、ミドルウェア、node.js、Python、Goをサポートするアプリケーションエンジンまで、多岐にわたります。さらに、アプリケーションサービス向けのエコシステム統合も含まれます。
コンテナを導入している多くの組織と同様に、Kubernetes環境内でDockerイメージをデプロイしている可能性が高いでしょう。
そして、それを行っているのであれば、脆弱性のあるコンテナイメージもデプロイしている可能性があります。前述のSnykの調査では、「最も人気の高いデフォルトのDockerイメージ上位10件には、それぞれ少なくとも30個の脆弱なシステムライブラリが含まれている」ことが判明しました。さらに同レポートは、「多くのDockerイメージでシステムライブラリが利用可能になっているのは一般的です。これは、通常Linuxディストリビューションをベースとする親イメージに依存しているためです」と指摘しています。

つまり、多くの組織が脆弱性を含むイメージを日常的に大量にダウンロードしています。Snykによると、主要な3つのLinuxディストリビューションすべてで、脆弱性の数が着実に増加しています。
したがって、Tripwireの「2019 State of Container Security」で、回答者の実に60%が過去12か月間にコンテナセキュリティインシデントを経験していたことが明らかになったのも不思議ではありません。5社に1社近く(17%)では、組織が脆弱性を認識しながらも、そのイメージをデプロイしたことが原因と考えられます。一方、Snykの調査では、既知の脆弱性が見つかったDockerイメージの44%について、より新しくセキュアなベースイメージが利用可能だったことが判明しています。つまり、最新のイメージをプルするだけでリスクを軽減できた可能性があります。また、脆弱性のあるイメージのうち、さらに22%は、イメージを再ビルドするだけで対処できた可能性があります。
本当です。作り話ではありません。
「セキュリティのシフトレフト」で重視されるのは、開発とデリバリーのライフサイクルにセキュアなプラクティスを組み込むことだけではありません。適切なセキュリティアプリケーションサービス(BOT対策、Webアプリケーションファイアウォール、IDおよびアクセス制御)を導入することも同様に重要です。こうしたプラクティスには、コードやコンテナをスキャンして既知の脆弱性を検出し、その後、対処することが含まれます。
この強調は、コンテナイメージに脆弱性があることを認識しながら、修正せずにデプロイした17%の方々に向けたものです。
もっと適切に対処できるはずです。確かにスピードは重要ですが、セキュリティを伴わないスピードは、組織だけでなく、急いでリリースしたアプリを最終的に利用するお客さまにとっても危険です。
安全なコンテナ化をまだ実践していない場合は、次の手順の導入をご検討ください。
- 利用状況を把握する多くの組織は、オープンソースやサードパーティ製のソース/イメージを実際にどの程度広く利用しているかを把握していません。まず、その利用状況を把握することが重要です。使用していることすら認識していないソフトウェアの脆弱性には対処できません。
- 標準化。 アプリケーションと運用の共通点を見いだし、使用するコンテナイメージやコンポーネントを可能な限り少数に絞って標準化します。これにより、セキュリティ上の負担を組織全体で分担でき、最終的には全員にとってより優れたセキュリティにつながります。
- セキュアなコードレビュー。 サードパーティ製のコンポーネントやスクリプトを使用している場合(ほぼ確実に使用しているはずです)は、それらをレビューし、プライベートリポジトリから配布またはビルドしてください。
- セキュアなコンテナ監査。サードパーティ製イメージを使用する場合は、そのセキュリティを監査・認証したうえで、プライベートリポジトリから配信してください。
- セキュリティチャネルを購読する。 イメージやソースコードを利用している場合は、潜在的な脆弱性に関する情報が発信されるチャネルを確認し、購読してください。情報を把握することが、対策の第一歩です。
著者について

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。
Lori Mac Vittieのその他のブログ記事関連するブログ記事

F5 Application Study Tool:OpenTelemetryによるF5 BIG-IP環境の監視
F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。
F5 BIG-IPでAI防御を実現
F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。
F5 Advanced WAFによるGraphQL APIの保護
ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。
アプリケーションサービスの現状 通信業界版:リーダーとしての台頭
通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。
デジタルトランスフォーメーションは、単なるペーパーレス化ではない
デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。
やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。