コンテナレジストリのセキュリティ

Snykの重要な原則の一つは、「開発者ファースト」です。製品ビジョンにおいてこれは、強力な製品連携によって開発者が既に使っているワークフローやツールに自然に溶け込み、開発者がセキュリティをできるだけシームレスに担えるようにすることを意味します。

つまり、開発者が普段使っている場所でセキュリティに取り組めるようにしたいと考えています。たとえば、次のような場所です。

• IDE内（2018年後半にリリースしたIntelliJプラグインなど）

• Gitレベル（開発者はプルリクエストを作成して、現在の問題を修正し、将来の問題を防げます）

• ビルド段階（ゲートとして機能し、Gitを補完する、よりDevOps寄りの方法です）

• PaaSや実行環境（Pivotalのdroplet、buildpack、brokerとの連携など）

• JIRAやSlackなどのプロジェクト管理ツールやメッセージングツール内

コンテナレイヤーと潜在的なリスク

コンテナ（広義の意味で）は、IT業界に大きな変革をもたらした技術の一つであり、開発と運用の両面に新たなセキュリティ課題をもたらしています。たとえば、サーバーや仮想マシンが主流だった時代、多くの企業チームは「ゴールデンイメージ」方式を使い、アプリケーションのベースレイヤー（OSやパッケージ）に対する運用チームの管理を維持していました。しかし、Dockerイメージの構築、配布、利用方法を考えると、クラウドベースのチームがこの方式に従うのは現実的ではありません。コンテナイメージには多数のレイヤーがあり、その出所や堅牢性が必ずしも明確ではないためです。

Snykのコンテナ脆弱性管理機能は、Dockerイメージを検査してOSパッケージと主要なバイナリの両方をスキャンし、その結果を独自の脆弱性データベースと照合します。これにより、イメージのレイヤーに隠れた直接依存関係と間接依存関係の両方を把握できます。以下のスクリーンショットでは、Snykが5階層下まで調査し、重大度の高い問題を検出している様子がわかります。

リスクの検出は、最初の一歩にすぎません。次の課題は、開発の流れを止めずに修正することです。そのため、ツール内で修正方法を提案しています。また、誤検知を抑えるために、信頼できる情報を基盤とすることも重要です。Snykの業界をリードする脆弱性データベースが、それを可能にします。

しかし、安全な開発者が取り組むべきことはそれだけではありません。次の段階では、侵害されている可能性のあるイメージをコンテナレジストリに送信する際のセキュリティ課題があります。これを手作業で行い、厳重にセキュリティを確認するのは非効率的です。一方、必要なガードレールなしに自動化すると、運用管理や監査がはるかに難しくなる可能性があります。Snykは、適切なセキュリティプラクティスに基づく自動化を目指しており、次の例でその方法をご紹介します。

Hello-ACR-world

こちらのデモアプリを作成し、Azure Container Registry（ACR）に送信されるすべてのDockerイメージをスキャンできるようにしました。開発サイクルを遅らせるのではなく、この例ではスキャンと修正の提案をACR Tasksのフローに組み込んでいます。以下の.yamlファイルからわかるように、標準のACR TasksであるBUILDとPUSHの間に、イメージとアプリ（バイナリ）の両方のレベルで脆弱性をスキャンするスクリプトを追加しています。

OSの重大度の高い脆弱性、またはアプリの重大度が中〜高の脆弱性が見つかった場合、PUSHを失敗させるように設定されています。この場合、スキャンを失敗として終了し、PUSHには進みません。以下の短い動画では、このプロセスをもう少し詳しくご覧いただけます。

要点

コンテナモデルには、セキュリティとコンプライアンスに関する新たなリスクが潜んでいます。Snykのコンテナ脆弱性管理を活用すれば、コンテナイメージ内の直接依存関係と、特に重要な間接依存関係にある脆弱性を検出し、修正できます。さらに、修正されていないイメージがコンテナレジストリに送信される前にSnykをゲートとして追加することで、DevOpsの自動化を一段と進められます。こうしたステップに、ソース管理、CI/CD、PaaSにおけるSnykの機能を組み合わせることで、コンテナをエンドツーエンドで保護する強力なユースケースが実現します。

現在お使いのコンテナレジストリや、効率性とセキュリティのバランスを取るためにどのような自動化を行っているか、ぜひお聞かせください。