Amazon Inspectorで始める脆弱性管理！「具体的にどう減らすか」まで検証してみた

AWS

城山浩輝

2026年03月24日

はじめに

こんにちは。株式会社メンバーズデプオプスリードカンパニーでエンジニアをしている城山です。

デプオプスリードカンパニーでは、毎週金曜日の午後を自社業務の時間として確保しており、各自興味のあるテーマを学習・検証するLab活動を行っています。

私が所属するチームでは、DevSecOpsに関する学習・検証を行っています。

今回は、Operationフェーズに関するAmazon Inspectorについて検証を行いました。

私はこれまで、Amazon Inspectorを有効にした後、具体的にどう脆弱性を減らせば良いのかイメージできていませんでした。

同じように、「Amazon Inspectorを有効にしたものの、検出された脆弱性をどうやって修正していけばいいのか分からない」といった悩みを持つ方や、そもそもAmazon Inspectorについて知らない方に向け、検証の様子をご紹介したいと思います。

Amazon Inspectorとは

そもそもAmazon Inspector（以下、Inspector）とは、EC2やECR、Lambda、コードリポジトリのそれぞれで脆弱性検知を行えるサービスです。

Amazon EC2インスタンス: OSやインストール済みソフトウェアの脆弱性、ネットワーク設定の誤りを検出。
Amazon ECR (コンテナイメージ): イメージ内のOSおよび言語パッケージの脆弱性を検出。
AWS Lambda関数: アプリケーションコードの脆弱性やプログラミング言語パッケージの脆弱性を検出。
GitHubなどのコードリポジトリ: CI/CDパイプラインに組み込み、リポジトリ内でプログラミングパッケージ（例：npmなど）のスキャンを行うことで、アプリケーションをデプロイする前に脆弱性を検出。

定期スキャンの機能はなく、新しいCVE（脆弱性情報）が提供されたときや、EC2インスタンス起動時や新しいECRイメージがプッシュされた際にスキャンされます。

ここからは推測ですが、Inspectorのユースケースとしては定常的に使われているリソースに適用すると思われ、CVEデータベースの更新も高頻度なことから、1日1回などのスキャンを行う必要性がないとしているのかもしれません。

また、InspectorはSecurity Hub CSPMと統合することにより、Inspectorの結果をSecurity Hub CSPMに送信、分析することができます。

Security Hub CSPMについて解説している記事も公開予定ですので、公開されましたらそちらもぜひご覧ください！

有効化

今回はTerraformによって有効化しました。検査の対象としてまずはEC2インスタンスを想定していました。そこで、以下のTerraformコードで有効化を行いました。

data "aws_caller_identity" "current" {}

resource "aws_inspector2_enabler" "main" {

  account_ids    = [data.aws_caller_identity.current.account_id]
  resource_types = ["EC2"] # ここに"ECR"が足りなかった
}

しかし、今回使用したAWSアカウントは検証用のため、常時EC2インスタンスを起動していません。たとえ起動時のスキャンが実行されても、結果が全て出力されるまでにEC2インスタンスを起動させ続ける必要があること、検証用に立ち上げたEC2インスタンスが新しく、脆弱性がない状態のため、検出までに時間がかかることが想定されました。

そこで今回は、ECRを使って検証を行うことにしました。

しかし、Inspectorのダッシュボードを確認しても、ECRの値が取れていません。

上記のTerraformコードを見ていただければわかるように、resource_typesがEC2のみになっているため、ECRスキャンが有効になっていませんでした。

検証時はTerraformのコードを見逃しており、ECRコンソールでスキャンタイプを拡張スキャン に設定しました。

その後、Terraformコード上にてresource_types にECRを設定し、コードとリソースの差分を無くしておきました。

最初からコードを変更すれば早かったですが、マネジメントコンソールとTerraformコードの関連性を発見でき、これはこれで良かったと思います。

結果の確認

今回は検証のため、脆弱性が含まれているイメージをPushする必要があります。今回はDocker Hubからpython:3.15.0a6-bookwormを選びました。

Docker Hub上で表示されている脆弱性は以下の通りです。

Critical 0件
High 4件
- CVE-2026-2006
- CVE-2026-2004
- CVE-2026-2005
- CVE-2026-25646
Medium 8件
- CVE-2026-22801
- CVE-2026-22695
- CVE-2025-15366
- CVE-2025-14831
- CVE-2026-2003
- CVE-2025-45582
- CVE-2009-3546
- CVE-2007-3996
Low 169件
Unspecified 4件

これらがInspector上でどのように検知されるかを確認してみたところ、以下のようになりました。

コンソール上だと少々結果が見づらいので、CSVで出力します。

CSVで出力する際は、エクスポート先のS3バケットと、Inspectorが使用するKMSキーを作成する必要があります。

ダウンロードしたCSVを確認した結果、一番検知されて欲しいものである、Docker HubのHigh 4件はInspectorで検知されていました！

Mediumの以下のものが検出結果にはありませんでした。

CVE-2025-45582
CVE-2009-3546
CVE-2007-3996

改善の手法と、結果について

実際に運用する場合は、他のパッケージや既存のアプリケーションとの兼ね合いから、ベースイメージをbookworm（Debian 12）で揃えたいはずです。しかし、Criticalがないためかpython:3.15.0a6-bookworm より新しいものはリリースされていません。

この場合、どうしたら良いかと悩んでいると、Labチームメンバーから、ベースイメージはそのままで、Dockerfile内でapt-get upgradeを行い、手動で脆弱性を解消するのが良いのではという意見が出ました。

ECRスキャンでは、コンテナイメージのOSパッケージやプログラミング言語のライブラリをスキャンしていることから、OSパッケージのアップデートを行う apt-get upgradeが有効ではないのかというのが理由です。

具体的には、以下のDockerfileを適用します。

FROM python:3.15.0a6-bookworm@sha256:0921ced562f7888c720464747446d241a777906e18f2e5f667e09e64c2ad6469

USER root

RUN apt-get update && \
    apt-get upgrade -y && \
    apt-get clean && \
    rm -rf /var/lib/apt/lists/*