Kubernetes がコンテナ戦争に勝利したことは誰もが知っています。 ただし、Kubernetes が勝利したのはコンテナランタイム戦争です。 ご存知のとおり、コンテナ イメージ戦争は Docker が勝利しました。 これは、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 年コンテナ セキュリティの現状調査で、回答者の 60% が過去 12 か月間にコンテナ セキュリティ インシデントを経験したという驚くべき結果が出たのも不思議ではありません。 ほぼ 5 分の 1 (17%) の場合、組織が脆弱性を認識していたものの、それをそのまま導入したためであると考えられます。 これは、既知の脆弱性が含まれていることがわかった Docker イメージの 44% に対して、より新しく、より安全なベース イメージが利用可能であったことを Snyk が発見したにもかかわらずです。 言い換えれば、最新のイメージを取得するだけでリスクは軽減されます。 脆弱性のあるイメージのさらに 22% は、イメージを再構築するだけで対処できた可能性があります。
本当に。 こんなことは作り話ではありえない。
「セキュリティのシフト レフト」に重点が置かれているのは、開発および配信ライフサイクルに安全なプラクティスを組み込むことと同じくらい、適切なセキュリティ アプリケーション サービス (BOT 防御、Web アプリケーション ファイアウォール、ID およびアクセス制御) を展開することに重点を置いているからです。 これらのプラクティスには、コードとコンテナをスキャンして既知の脆弱性を検出し、それらに対処することが含まれます。
これは、コンテナ イメージの脆弱性を認識していたものの、修正せずにデプロイした 17% のユーザーに向けたものです。
我々はこれよりも良いことができるはずだ。 確かに、速度は重要ですが、セキュリティのない速度は、組織だけでなく、急いでリリースしようとしているアプリを最終的に使用する顧客にとっても危険です。
安全なコンテナ化をまだ実践していない場合は、次の手順を実践することを検討してください。