[アップデート]Amazon Inspector が ECR上のWordPressやGo ツールチェーンの脆弱性、EOLOS の検出に対応しました
お疲れさまです。とーちです。
Amazon Inspector が ECR のサポートを拡張したというアップデートがありました。今回はこの新機能を実際に試してみた内容を紹介します。
とりあえずまとめ
- Amazon Inspector の ECR サポートが拡張され、scratch イメージ、distroless イメージ、Chainguard イメージのスキャンをサポートするようになりました
- Go ツールチェーン、WordPress など多くの追加エコシステムの脆弱性検出が強化されました
- 廃止されたオペレーティングシステム(EOL OS)の識別がサポートされるようになりました
アップデートの概要
今回のアップデートの主な変更点は以下の通りです
-
最小限のコンテナベースイメージのサポート
- scratch イメージ
- distroless イメージ
- Chainguard イメージ
-
追加エコシステムへの拡張
- Go ツールチェーン
- Oracle JDK & JRE
- Amazon Corretto
- Apache Tomcat
- Apache httpd
- WordPress (コア、テーマ、プラグイン)
- Google Puppeteer (Chrome 埋め込み)
- Node.js ランタイム など
-
その他の機能強化
- Amazon Inspector SBOM スキャン API でも同じ機能を利用可能
- 廃止されたオペレーティングシステム(EOL OS)の識別をサポート
scratch イメージとは?
distroless イメージは知っていたんですが、scratch イメージについては知らなかったので調べてみました。scratch イメージとは以下の特徴を持っており、セキュリティ面では攻撃対象領域が最小限になるメリットがあります。
- 完全に空のコンテナイメージ
- Docker の最も基本的なベースイメージ
- FROM に scratch を指定することで、アプリケーションの実行に必要な最小限のバイナリのみを含めることができる
scratch イメージとして有名なものとしては busybox になるかと思います。以下のように FROM に scratch が指定されています。
Go ツールチェーンのサポート
また、Go ツールチェーン(Go のコンパイラ自体やパッケージマネージャー等)等は今まで ECR での脆弱性スキャンの対象外でした(Go で書かれたアプリケーションが使用するライブラリやパッケージの脆弱性がスキャン対象だった)。以下は Inspector の公式ドキュメントからの引用ですが、2025/3/13 時点では以下の記載になっています(おそらくそのうち修正されると思います)
Supported programming languages: Amazon ECR scanning
Amazon Inspector currently supports the following programming languages when scanning container images in Amazon ECR repositories:
Note
Amazon Inspector doesn't scan for toolchain vulnerabilities in Go and Rust. The version of the programming language compiler used to build the application introduces these vulnerabilities.
C#
Go
Java
JavaScript
PHP
Python
Ruby
Rust
今回のアップデートによりこういった Go ツールチェーンや WordPress 自体の脆弱性のスキャンもサポートされるようになりました。
廃止された OS の識別サポート
もう一つの大きな見どころとしては「廃止されたオペレーティングシステムの識別をサポート」という部分でしょう。これについては実際のスキャン結果を見たほうがわかりやすいと思うので後ほど見ていきます。
なお Inspector が廃止された OS として認識している一覧は以下のページに記載があります
実際に試してみる
それでは実際に新機能を試してみましょう。
ECR リポジトリの作成
とりあえず適当に ECR リポジトリを作成しました。
今回のアップデートは Inspector のアップデートなので、ベーシックスキャンは対象外ですが、違いを見るために、ベーシックスキャンでもスキャンしてみます。
WordPress の脆弱性検出テスト(ベーシックスキャン)
以下のページを見ると WordPress 6.5 から 6.5.1 までのバージョンで CVE-2024-4439 という識別子で Severity:High の脆弱性があったようです。
そこで以下のコマンドで 6.5.0 のイメージを pull して push してみます。
docker pull wordpress:6.5.0-fpm
docker tag wordpress:6.5.0-fpm ***.dkr.ecr.ap-northeast-1.amazonaws.com/ecr-update-test:wordpress_6.5.0-fpm
docker push ***.dkr.ecr.ap-northeast-1.amazonaws.com/ecr-update-test:wordpress_6.5.0-fpm
こちらをベーシックスキャンでスキャンしてみます。CVE-2024-4439 で検索してみましたが、脆弱性は検出されていないようです。
廃止された OS の検出テスト(ベーシックスキャン)
廃止されたオペレーティングシステムの識別についても確認してみました。Ubuntu (Hirsute) 21.04 は January 20, 2022 に廃止となっていますので、このイメージを pull して push してみます。
docker pull ubuntu:21.04
docker tag ubuntu:21.04 ***.dkr.ecr.ap-northeast-1.amazonaws.com/ecr-update-test:ubuntu_21.04
docker push ***.dkr.ecr.ap-northeast-1.amazonaws.com/ecr-update-test:ubuntu_21.04
同じく ECR のイメージの詳細画面から結果を確認してみると以下のように表示されていました。なるほど、おそらく脆弱性はあると思うのですが、こういうふうになってしまうんですね。
Inspector のドキュメント上にも以下の記載がありましたのでそういうことなんでしょう。
ベンダーは、標準サポートの終了に達したオペレーティングシステムのフィードから既存のセキュリティアドバイザリと検出を削除することができます。その結果、Amazon Inspector は既知の CVE の検出結果を生成しなくなる可能性があります。
しかしこの結果を見て脆弱性がないと勘違いしてしまう人はいそうですね。
Inspector 拡張スキャンの有効化
それでは、Inspector を有効にしたうえで、同様にスキャンをし、結果がどうなるか見てみましょう。
Inspector の画面に移動し、「Inspector をアクティブ化」ボタンを押します。
ECR リポジトリの画面に戻りスキャン設定を見ると拡張版になっていることが確認できました。
WordPress の脆弱性検出テスト(拡張スキャン)
では先程と同じように wordpress:6.5.0-fpm
のイメージをスキャンしてみましょう。一応イメージは一度消してから push し直しました。
ECR のイメージの詳細画面から結果を確認してみます。イメージを push すると自動でスキャンが開始されます。しばらく待つと結果画面が表示されたので CVE-2024-4439
で検索してみます。
すると上記のように見事に WordPress 自体の脆弱性が検知されていました(「脆弱性:重要」の数がベーシックスキャンより減っているのが謎ですが...)。
廃止された OS の検出テスト(拡張スキャン)
廃止されたオペレーティングシステムの識別のサポートについても見てみましょう。Ubuntu (Hirsute) 21.04 を再度 push してみます。
同じく ECR のイメージの詳細画面から結果を確認してみると以下のように表示されていました。おお〜、これは便利ですね。
ちなみに Inspector の画面からだと少し見え方が変わります。こちらのほうが EOL であることが直感的にわかりますね。
distroless イメージも試してみる
distroless イメージをFROMに指定したコンテナイメージは(私の記憶では)以前からスキャンできていたと思います。以前のスキャンは distroless イメージに各ランタイムのパッケージマネージャ等で追加したパッケージやライブラリがスキャン対象だったのではないかなと思います。今回のアップデートは distroless イメージ自体の脆弱性をスキャンできるようになったということなのかなと理解しています。
ということで distroless の各ランタイムのベースイメージとなる gcr.io/distroless/base
で脆弱性が検出されるか試してみたいと思います。gcr.io/distroless/base-debian12
だと脆弱性が検出されないかもしれないので gcr.io/distroless/base-debian11
で確認します。
docker pull gcr.io/distroless/base-debian11
docker tag gcr.io/distroless/base-debian11 ***.dkr.ecr.ap-northeast-1.amazonaws.com/ecr-update-test:distroless_debian11
docker push ***.dkr.ecr.ap-northeast-1.amazonaws.com/ecr-update-test:distroless_debian11
すると脆弱性が検出されました。今回のアップデート以前からこの脆弱性が検出できたかどうかを確認するのは難しいのですが、distroless イメージの基本コンポーネントの脆弱性も検出できるということで参考にして頂ければと思います。
余談
scratch イメージの脆弱性を検出できるかを確認したかったので busybox のイメージを push してみましたが、これは私のやり方が悪いのかうまくいきませんでした。もしうまく脆弱性スキャンできた方がいたらぜひ X(@tttkkk215)で教えて頂けると助かります。
以下、私が検証したときのメモになります。
調べてみると busybox の 1.35.0 で CVSS スコア 8.8 の脆弱性があったようです。
以下のコマンドで 1.35.0 のイメージを pull して ECR に push してみます。
docker pull busybox:1.35.0
docker tag busybox:1.35.0 ***.dkr.ecr.ap-northeast-1.amazonaws.com/ecr-update-test:busybox_1.35.0
docker push ***.dkr.ecr.ap-northeast-1.amazonaws.com/ecr-update-test:busybox_1.35.0
push されました。
スキャンタイプが拡張版になっていることを確認して、イメージの詳細画面を見てみました。しばらくスキャン実行されるのを待ってみましたが、UnsupportedImageError
となりました。
まとめ
今回は、Amazon Inspector の ECR サポート拡張について実際に試してみました。主な発見は以下の通りです
-
WordPress の脆弱性検出
- ベーシックスキャンでは WordPress 自体の脆弱性(CVE-2024-4439)は検出されなかった
- Inspector の拡張スキャンでは WordPress の脆弱性が検出された
-
廃止された OS の検出
- ベーシックスキャンでは EOL OS に対して脆弱性が検出されない
- Inspector の拡張スキャンでは EOL OS であることが明確に表示される
この拡張機能によって、最小限のコンテナイメージを使用している場合や、Go ツールチェーンや WordPress などの特定のエコシステムを使用している場合に、より正確な脆弱性検出が可能になりました。特にEOL OS の明確な識別はいいですよね。どんどん活用して頂ければと思います。
以上、とーちでした。