Snykの新しい親イメージ自動検出でコンテナの修正を迅速化

アプリをコンテナで提供すれば、他の人の成果を土台にして自由に開発できます。すぐに使えるさまざまなコンテナイメージから選び、ほぼあらゆるコードやフレームワークを実行できます。Snyk Containerはすでに、親イメージの管理を支援し、より適切な選択肢（脆弱性が少ないイメージや、全体のフットプリントが小さいイメージ、またはその両方）を利用できる場合に案内しています。このたび、イメージ管理機能をアップデートし、ベースイメージの自動検出に対応しました。

イメージセキュリティのワークフローをシンプルに

今回のリリース以前は、Snyk Containerがスキャン対象のコンテナイメージの親イメージを特定するには、コンテナイメージのテスト時に--file=/path/to/Dockerfileオプションを使い、Dockerfileを解析する必要がありました。Dockerfileがすぐに使える状態であり、スキャン時にDockerfileを追加するのを忘れなければ、これは便利な方法です。しかし、Dockerfileの追加はひと手間かかりますし、他のイメージスキャナーの使い方ともかなり異なります。ベースイメージの管理をもっと簡単にし、Snykで初めてスキャンする際からベースイメージを推奨できるようにするため、ベースイメージを自動検出する機能を実現しました。Snykでコンテナイメージをスキャンするだけで、あとはお任せください。

上の例では、非常に古いnode:10をベースにしたコンテナで動作するデモアプリをスキャンしました。スキャン中にSnyk Containerは使用されている親イメージnode:10を検出し、構築したイメージに含まれる脆弱性を520件以上解消できる、より適切な代替イメージを推奨します。コンテナのベストプラクティスでは、攻撃対象領域を減らすために小さいベースイメージを選ぶことがほぼ必ず推奨されています。コンテナの脆弱性をテストすれば、その理由はすぐにわかります。大きなイメージや古いイメージを使うと、多くの脆弱性が持ち込まれるためです。多くの場合、新しくて軽量なイメージを選ぶことが、脆弱性を減らすうえで最も大きく、迅速な効果をもたらします。一方、コンテナの脆弱性を一つずつ修正したり、公開リポジトリにある何百ものベースイメージの選択肢を調べたりするのは、誰にとっても時間の有効な使い方とは言えません。そこでSnyk Containerは、Docker Hubで特に人気のあるイメージについて、この作業を代わりに行います。

下の例では、ベースイメージにruby:2.6-slimを使った別のアプリをスキャンしました。Nodeイメージとは異なり、このイメージは脆弱性が比較的少なく、適切な選択肢です。もっとも、コンテナイメージを最近ビルドしていればの話ですが。実際には、約7か月前にビルドしたイメージでした。そのため、代替ベースイメージではなく、Rubyイメージが古くなっているため、脆弱性を修正するには再ビルドが必要だという通知が表示されます。なお、ここでは--jsonオプションを使って、機械可読なJSON出力を表示しています。Snykの結果を他のツールに取り込みたい場合に便利です。

より多くのコンテナビルド方法に対応

ベースイメージの自動検出が重要な理由は、ほかにもあります。Dockerfileを使わずにコンテナをビルドするツールが増えているのです。幸い、こうしたツールではOpen Container Initiative（OCI）のコンテナイメージ標準が広く採用されています。そのため、利用するコンテナツールやランタイムで、これらのコンテナを実行できるはずです。Jib、Buildah、Cloud Native Buildpacksなどのツールを使えば、Dockerfileを書かずにOCI準拠のコンテナを作成できます。

Snyk Containerは以前からこうしたコンテナをスキャンできました。今回、ベースイメージの自動検出機能が加わったことで、こうした別のビルドワークフローにもベースイメージのガイダンスを提供できるようになりました。今後数週間のうちにJibとCloud Native Buildpacksに関するブログを公開する予定ですが、待ちきれない方は、お好きなツールでコンテナをビルドしてスキャンしてみてください。

ベースイメージ検出の仕組み

この機能では、コンテナのベースイメージを検出して推奨事項を提供する方法が2つあります。

1. スキャン時にDockerfileを検査する：すでにこの方法をお使いの場合は、引き続きご利用いただけます。Snyk Containerはこれまでと同様に動作します。自動検出ではなく、Dockerfileを情報源としてベースイメージの詳細を特定します。

2. イメージレイヤーを検査する：スキャン時にイメージのレイヤーを分析することで、使用されているベースイメージを特定できます。Snyk Containerは、Docker Hubで公開されている特に人気の高いDocker公式イメージを分析し、それらのイメージのレイヤーデータを追跡します。これにより、スキャン対象イメージのレイヤーを記録と照合できます。

現在は、Docker Hubで公開されている特に人気の高い公式イメージを対象としています。Debian、Alpine、UbuntuなどのLinuxディストリビューションだけのベースイメージ、Python、Node、OpenJDKなどの言語やフレームワークのパッケージが組み込まれたイメージ、NGINX、WordPress、Mongo、MySQLなどのアプリコンポーネントがあらかじめビルドされたイメージが含まれます。対象となるイメージはほかにも多数あり、引き続き追加しています。対応してほしいイメージがあれば、ぜひお知らせください。

それでもDockerfileをスキャンすべき理由

Snyk Containerがベースイメージを自動で検出するようになった今、Dockerfileのスキャンは不要だと思えるかもしれません。しかし、安全な開発プラクティスにDockerfileを含める（使用している場合）ことには、今も次のような理由があります。

1. 早期警告：GitリポジトリをSnykにインポートすると、Dockerfileがあるかどうかを確認します。これにより、より適切なベースイメージが利用できる可能性を、できるだけ早くお知らせできます。さらに、ソースリポジトリと連携しているため、プルリクエストを通じてベースイメージの修正を自動化することもできます。

2. 出所の追跡：Snyk ContainerでDockerfileと、そこから作成されたコンテナイメージの両方をスキャンすると、それぞれの結果を関連付けられます。環境内のイメージがどこから来たのかを追跡したり、稼働中の本番コンテナをソースに結び付けたりする際に役立ちます。

3. 網羅性：Git上のDockerfileをスキャンすると、ベースイメージの選定について早期に警告を受け取れますが、ベースイメージの推奨を提供するだけにとどまります。Linuxパッケージやベースイメージは頻繁に更新されるため、Dockerfileからビルドされるイメージの内容は、ビルドした時期によって異なるからです。Dockerfileだけでは、すでにビルドしたイメージに実際に何が含まれているかはわかりません。また、Dockerfileは多くの場合、コンテナで実行されるコードと一緒に保存されています。そのため、コンテナの問題と同時に脆弱性やコードの問題を確認することで、さらに詳しい状況を把握できます。

Dockerfileとイメージの両方をスキャンすれば、ベースイメージやイメージの他のレイヤーに起因する脆弱性を含め、全体像を把握できます。さらに、ソースファイルに直接移動してすばやく修正できます。

利用を開始するには

Snykのベースイメージ検出機能とガイダンスを試してみたい方は、簡単に始められます。Freeプランを含むすべてのプランでご利用いただけます。Dockerの人気公式ベースイメージのいずれかを使ってイメージをビルドし、Snyk Containerでスキャンするだけです。Snyk CLIのバージョン1.677以降をお使いであれば、ベースイメージの自動推奨が表示されます。CI/CDパイプラインやコンテナレジストリのイメージもスキャンできます。また、Snyk BusinessまたはEnterpriseプランをご利用の場合は、Kubernetesクラスターで稼働中のコンテナもスキャンできます。いずれの場合も、同じベースイメージ検出とガイダンスを利用できます。