SDLC全体におけるコンテナセキュリティ

コンテナは、ソフトウェアの標準的な単位になりつつあります。OCIイメージ仕様で技術的に定義されるコンテナイメージは、DockerやKubernetesからAWS Fargate、Google Cloud Runのようなプラットフォームまで、最新のツールに欠かせない要素です。アプリケーションセキュリティにとって、これは何を意味するのでしょうか？

コンテナイメージの活用場所

コンテナイメージの興味深い点の一つは、ソフトウェア開発ライフサイクル（SDLC）全体に関わることです。

• イメージは開発者のローカル環境でビルドされ、ソフトウェアを簡単に（時には簡単すぎるほど）配布する便利な手段となります。

• イメージは、継続的インテグレーションと継続的デリバリーのパイプラインの一部としてもビルドされます。アプリケーションのメタデータをイメージに付与すれば、アセット管理を改善できます。

• イメージはパブリックまたはプライベートのレジストリにアップロードされ、そこからデプロイ用に共有できます。

• そして最後に、開発・テスト環境から本番環境まで、クラスターにイメージがデプロイされます。こうした環境は、Kubernetesなどのツールで管理されることが増えています。

これらの各段階で、イメージにセキュリティ上の脆弱性がないかをテストできます。では、どの段階でテストするのが最適なのでしょうか？

イメージをテストする場所

コンテナイメージのセキュリティ対策を考えるとき、SDLCのどこか1か所でテストすればよいと思いがちです。たとえば、レジストリに安全なイメージだけがあれば、セキュリティは万全でしょうか？実際はもっと複雑で、一般にトレードオフが伴います。

本番環境に近い段階でテストするほど、稼働中のアプリケーションのリスクを把握できているという確信が高まります。他者が利用するツールを開発するソフトウェアベンダーでない限り、今まさに本番環境で稼働しているアプリケーションの保護が主な関心事でしょう。また、利用している依存関係に新たな脆弱性が公表された場合、開発サイクルの後半でテストすることも有効です。どの本番アプリケーションが影響を受けるかをすばやく評価し、適切な緊急度で対処できます。

ただし、SSDLCの最後でのみテストすると、開発者へのフィードバックが遅くなる可能性があります。イメージの使用や変更を決めた開発者は、その上に構築を進め、すでに別の作業に移っているかもしれません。そのため、セキュリティ上の問題を解消するための変更は、作業を妨げ、コストもかさみます。重要なのは、脆弱性の可能性を把握すること（もちろん重要です）だけでなく、修正することです。ローカルでのテストは最も迅速にフィードバックを得られますが、開発者全員が毎回スキャンすることを忘れないのが前提です。網羅性を確保するのは難しく、現実的とは言えません。

だからといって、パイプラインがテストに最適な場所だと結論づける前に、導入コストも検討する必要があります。中央管理のコンテナレジストリが1つか2つなら、ビルドするすべてのイメージを評価できます。一方、継続的インテグレーションのパイプラインは、それよりはるかに多いでしょう。自動化のレベルや、組織内で各ツールを誰が管理しているかによっては、どちらか一方から始めるほうが効率的な場合もあります。

また、SDLCの各段階では、得られるコンテキストのレベルも異なります。ローカル環境やCIでテストする場合は、ソースコードとバージョン管理情報の両方を参照できる可能性があります。これにより、使用したコンパイラに起因する問題や、悪意ある攻撃者による署名のないコミットなど、特定の種類の問題を検出しやすくなることがあります。また、ライブラリがどのように導入されたかも把握しやすくなります。一方、本番環境でテストすれば、どのイメージがどこで使われ、どのように設定されているかを正確に把握できるため、見つかった問題の優先順位づけに役立つ場合があります。

まとめ

1か所だけでテストすると、開発者、運用担当者、セキュリティ担当者のいずれかのニーズは満たせるかもしれません。しかし、脆弱性をできるだけ迅速に発見して修正するという、ビジネス全体の目標を完全に達成することは難しいでしょう。要点をまとめると、次のとおりです。

SDLCの各段階における脆弱性テスト

どの方法から始めるかは、組織の状況によって異なります。ただし、理想的にはSDLC全体を通じて、コンテナベースのアプリケーションを徹底的にテストすることを目指しましょう。単一のゲートに頼るだけでは単純すぎて、開発者、運用担当者、セキュリティチーム間の摩擦や、アプリケーションのデプロイ速度の低下につながる可能性があります。