コンテナセキュリティの強固な基盤を築く

コンテナ化されたデプロイは、正当な理由から広く普及しています。コンテナを使えば、アプリケーションを自己完結型でポータブルなコード単位に変換できるため、開発者はより迅速かつ確実にアプリケーションをデプロイできます。しかし、コンテナベースのソフトウェアの普及に伴い、コンテナセキュリティの責任も開発者へと移りつつあります。コンテナスキャンは、開発者がコンテナの安全性を確保するための効率的な方法です。

ここでは、コンテナスキャンの基本と、自動コンテナスキャナーの仕組みを詳しく見ていきます。また、コンテナスキャナーが検出できる脆弱性の種類や、イメージレイヤーがコンテナセキュリティに与える影響についても解説します。

コンテナスキャンの基本

コンテナには、さまざまな経路から脆弱性が持ち込まれる可能性があります。コンテナ内のソフトウェア、ホストOSや隣接するコンテナとのやり取り、ネットワークやストレージの設定などがその例です。コンテナスキャナーは、こうしたコンテナの各種コンポーネントを分析し、セキュリティ上の脆弱性を検出する自動化ツールです。

イメージに追加したコードやツールが直接持ち込む脆弱性だけでなく、コンテナが依存するほかのイメージに問題がある場合もあります。こうしたイメージは、親イメージまたはベースイメージと呼ばれます（厳密には「親イメージ」がより正確です）。実際、コンテナイメージが、既知の脆弱性やマルウェアを含む公開イメージをベースにしていることもあります。特に、検証済みの提供元からイメージをダウンロードしていない場合や、提供元とイメージの内容を認証していない場合は注意が必要です。よく知られた信頼できるプロバイダーのイメージにも脆弱性が含まれていることは珍しくありません。それでも、イメージをスキャンして脆弱性を見つけ、親イメージとその脆弱性を特定すれば、多くの問題を一度の変更で修正できる場合があります。

セキュリティスキャナーは、開発のさまざまな段階に組み込むことができます。たとえば、イメージのベースにする親イメージを決める前に、デスクトップ上で候補をスキャンできます。一部のツールやIDEプラグインはDockerfileをスキャンし、脆弱性が少ない、またはサイズが小さい代替イメージを提示します。多くの組織では、コンテナの脆弱性スキャンを継続的インテグレーションと継続的デリバリーの（CI/CD）パイプラインに組み込んでいます。ここでは、デプロイ前に「実際に使う」イメージがビルドされることがよくあります。パイプラインでスキャンすれば、問題が多すぎるコンテナイメージがレジストリに保存されたり、本番環境に到達したりするのを防げます。ほとんどのチームは、Kubernetesなどのプラットフォームで実行中のコンテナ化されたデプロイも監視しています。そのため、コンテナセキュリティスキャンを導入すれば、開発者の負担を大きく増やすことなく、アプリケーションのセキュリティを大幅に高められます。

コンテナレジストリのスキャンも、組織内で頻繁に使われるすべてのイメージの脆弱性を減らすうえで効果的です。たとえば、SnykとDocker Hubのインテグレーションを使えば、開発者がコンテナのベースとして使える信頼性の高い公開イメージを利用できます。また、保存済みのイメージを継続的に監視して、既存のイメージに新たに公表された脆弱性がないかを確認し、今後それらが本番環境にデプロイされるのを防ぐこともできます。さらに、ほとんど変更されない古いイメージや、コンテナレジストリに保存されたサードパーティ製イメージも複数あるでしょう。こうしたイメージはCI/CDパイプラインを通らないため、レジストリからスキャンすることで安全に使用できるかどうかを判断できます。このように、レジストリスキャナーを使えば、開発者はコンテナ化されたデプロイに使用するイメージを安心して選べます。

検出できるコンテナの脆弱性とは？

前述のとおり、コンテナに脆弱性が持ち込まれる経路はさまざまです。安全でないアプリケーションコードや実行時の設定ミスから、ネットワーク上の脅威やアクセス制御の問題まで、コンテナの脆弱性は多岐にわたります。こうした脅威から保護するには、継続的なコンテナ監視と、新たな脆弱性が発見された際に常に最新の情報を把握することが必要です。

ほとんどのコンテナスキャンソリューションは、National Vulnerability Database（NVD）やCommon Vulnerabilities & Exposures（CVE）データベースなど、脆弱性情報を提供する公開ソースを活用しています。これらのデータベースは既知のエクスプロイトを公開し、自動化された脆弱性管理、セキュリティ測定、コンプライアンスを支援します。

Snykのセキュリティリサーチチームは、コンテナの脆弱性データを拡充し、膨大な数に見える脆弱性の優先順位を付けやすくしています。コンテナがKubernetesクラスターで実行されているかどうか、実行されている場合はどのように設定されているか、実証済みのエクスプロイトが利用可能か、ソーシャルメディアでどのような話題になっているか、Linuxディストリビューション固有の脆弱性情報などをもとに、Snyk Containerは対応の優先度が高い問題を簡単に判断できるようにします。

コンテナレイヤーが脆弱性の検出に与える影響

コンテナはモダンアプリケーションの構成要素です。コンテナを使う利点の一つは、ほかの人の成果を土台にして構築できることです。Dockerはこれを開発者にとって簡単にし、Docker Hubを通じてコンテナイメージを共有しやすくしました。また、Dockerは、幅広いプログラミング言語やフレームワーク、その他のアプリケーションサービスを網羅するDocker Official Imagesも提供しています。ほかの人の成果の上に独自のイメージを構築していくと、コンテナは複数の読み取り専用レイヤーと、最後の読み書き可能なレイヤーで構成されるようになります。

新しいレイヤーを追加するたびに、コンテナに新たな脆弱性が持ち込まれるリスクがあるため、使用するコンテナスキャナーがレイヤーごとに問題を検出できることが重要です。さらに、問題をそのレイヤーを作成したコマンドやDockerfileの命令と関連付けられると、開発者にとってなじみのある場所で変更できるため、より効果的です。また、イメージはほとんどの場合、DockerfileのFROMコマンドなどを通じて別のイメージをベースに構築されます。そのため、特定のレイヤーがDocker Official Imageであると特定し、脆弱性を減らす代替イメージを適切に提示できるSnyk Containerのようなコンテナ脆弱性スキャナーは、レイヤー情報をそのまま提示するだけのツールより優れています。コンテナ内のレイヤーが増えるほど、インストールされるパッケージも増える傾向があります。パッケージが増えれば脆弱性やリスクも増えるため、アプリケーションの要件を満たす範囲で、できるだけ軽量なイメージを使うことがベストプラクティスです。

包括的なコンテナセキュリティ

コンテナは複数のレイヤーで構成されているため、包括的なセキュリティを実現するには、独自コード、オープンソースの依存関係、コンテナ、Dockerfile自体、そして場合によってはInfrastructure as Code（IaC）ファイルの脆弱性をスキャンする必要があります。これらはモダンなクラウドネイティブアプリケーションを構成する要素であり、安全な開発ワークフローを構築するうえで重要な領域です。

Snykはクラウドネイティブアプリケーション向けに包括的なセキュリティスキャンツールを提供し、開発チームが開発プロセスの早い段階で脆弱性を簡単に検出・修正できるよう支援します。既存の開発ワークフローにシームレスに統合できるため、新たなセキュリティプロセスを開発チームに導入する際の負担を軽減できます。これにより、組織はセキュリティを開発の早い段階から組み込むことができ、コンテナやアプリケーションに対するセキュリティ対策を最初から実施できます。

Snyk ContainerはコンテナだけでなくDockerfile自体もスキャンし、脆弱性を引き起こした命令を特定するとともに、脆弱性の少ない親イメージの使用を推奨し、プルリクエストまで作成できます。セキュリティ上の問題をこうした詳細なコンテキストとともに把握できるため、開発者は悪用可能性に基づいて修正の優先順位を付けられます。最小限の変更で、コンテナやアプリケーションのセキュリティ態勢をすぐに改善できます。

コンテナスキャンに関するよくある質問

コンテナスキャンの仕組みとは？

コンテナの脆弱性スキャンでは通常、セキュリティツールを使ってコンテナイメージをレイヤーごとに分析し、潜在的なセキュリティ上の問題を検出します。多くのスキャンソリューションは既知の脆弱性データベースを活用しており、セキュリティ脅威の状況が変化しても、組織が最新の情報を把握できるようにします。コンテナ化されたアプリケーションは、カスタムコード、オープンソースの依存関係、イメージ、Dockerfileなど、複数のコンポーネントで構成されています。包括的なコンテナセキュリティを実現するには、これらすべてのコンポーネントを対象に脆弱性をスキャンすることが重要です。