Amazon Inspector の AMI スキャンで、約8か月前の Amazon Linux 2023 を更新して再スキャンしてみた

はじめに

2026-11-02 に、EC2 の AMI を Amazon Inspector でスキャンできるようになりました。インスタンスを起動せずに AMI の脆弱性を検出でき、イメージを使い始める前に対処できます。

https://aws.amazon.com/jp/about-aws/whats-new/2026/11/ec2-amis-scanned-through-inspector/

この記事では、約8か月前（2023.10.20260302.1、以下「3月版」）と最新（2023.12.20261102.0、以下「11月版」）の Amazon Linux 2023（AL2023）AMI をオンデマンドスキャンし、検出数を比べました。さらに3月版を dnf upgrade で更新して作り直し、残った検出を旧カーネルの撤去まで行って解消できるかも確かめました。

検証の方法

検証は 2026-11-03 に東京リージョン（ap-northeast-1）で、AWS CLI 2.39.3 を使って行いました。発表にある Allowed AMIs、EC2 Image Builder、Security Hub との連携は扱いません。

比較する4つの AMI

3月版には、カーネル 6.18 の AL2023 AMI を非推奨の版も含めて describe-images で列挙し、そのうち作成日が最も古い版を使いました。11月版には、検証時点で SSM パラメータが指していた版を使いました。そのパラメータは /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-6.18-x86_64 です。カーネルの系統を 6.18 で揃えたので、3月版と11月版の差はリリース更新で入る修正に絞られます。

以降、「3月版」「11月版」は公開 AMI のコピーを、「更新後」はそれを更新して作り直した AMI を、「旧カーネル撤去」は更新後にさらに旧カーネルの rpm を削除して作り直した AMI を指します。

スキャンの実行

1回限りのオンデマンドスキャンは、Inspector を有効化していないアカウントでも使えます。

オンデマンドスキャンには、対象の AMI、実行する権限、リージョンについて次の条件があります。

• 対象：自アカウントが所有する AMI であること
• AMI：EBS-backed で状態が available であり、単一の OS を含み、ファイルシステムが ext3、ext4、ntfs、xfs のいずれかであること。LVM を使う AMI は UNSUPPORTED_OS になります。AL2023 は対応 OS です
• 権限：実行するユーザーまたはロールに inspector2:StartOnDemandScan と iam:CreateServiceLinkedRole が必要
• 同時実行：同じ AMI に対して同時に実行できるスキャンは1つまで
• リージョン：商用リージョンで利用可能

対象の公開 AMI を copy-image で自アカウントへコピーし、そのコピーをスキャンします。

$ aws ec2 copy-image --source-image-id ami-0a1b2c3d4e5f60001 --source-region ap-northeast-1 --name devio-al2023-old-20260302-copy
$ aws ec2 copy-image --source-image-id ami-0a1b2c3d4e5f60002 --source-region ap-northeast-1 --name devio-al2023-new-20261102-copy

コピーした AMI ごとにスキャンを開始し、状態を確認します。--resource-type には AMI を指定します。

$ aws inspector2 start-on-demand-scan --resource-id ami-0fedcba9876543210 --resource-type AMI
$ aws inspector2 get-on-demand-scan-status --resource-id ami-0fedcba9876543210 --scan-id <scan-id> --resource-type AMI

最初の start-on-demand-scan は AccessDeniedException になりました。サービスにリンクされたロールは、この呼び出しと同じ秒に作成されていました。約50秒後に再実行すると、スキャンが始まりました。

オンデマンドスキャンの料金は、成功したスキャンごとに発生します。失敗したスキャンには課金されません。同じ AMI を再スキャンした場合は、その回にも課金されます。オンデマンドスキャンは無料トライアルの対象外です。AWS Price List API で確認すると、東京リージョンの単価は1回あたり 0.51 USD でした。

AMI の更新

AL2023 の AMI は、作成時点のリポジトリバージョンに固定されています。AMI から起動したインスタンスが、新しいリリースの更新を自動で受け取ることはありません。明示的にリリースを指定して上げると、そのリリースが以後の既定になります。

https://docs.aws.amazon.com/linux/al2023/ug/deterministic-upgrades.html

各コピーから t8i.micro を起動しました。2026-03 作成の3月版も t8i.micro で起動できました。更新には user-data で次の3つのコマンドを実行しました（出力系の行は省略しています）。

#!/bin/bash
dnf check-release-update
dnf upgrade -y
dnf upgrade -y --releasever=latest

3月版から起動したインスタンスの出力から、更新前後の状態を示す行を抜粋します（--- の行は user-data が出力した見出しです）。

PRETTY_NAME="Amazon Linux 2023.10.20260302"
--- dnf check-release-update
    Run the following command to upgrade to 2023.12.20261029:

      dnf upgrade --releasever=2023.12.20261029

    Release notes:
     https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes-2023.12.20261029.html

  Version 2023.12.20261102:
    Run the following command to upgrade to 2023.12.20261102:

      dnf upgrade --releasever=2023.12.20261102

    Release notes:
     https://docs.aws.amazon.com/linux/al2023/release-notes/relnotes-2023.12.20261102.html
--- dnf upgrade -y (releasever 指定なし)
Dependencies resolved.
Nothing to do.
Complete!
--- kernel packages (after)
kernel6.18-6.18.56-125.164.amzn2023.x86_64
kernel6.18-6.18.8-9.213.amzn2023.x86_64
--- os-release (after)
VERSION="2023"
PRETTY_NAME="Amazon Linux 2023.12.20261102"

dnf upgrade -y は固定された 2023.10 リリース内しか見ないため更新対象がなく（Nothing to do）、--releasever=latest を付けると新しいリリースを参照してリリースが上がりました。リリースを上げた後も旧カーネルは削除されず、新しいカーネルと並んで残りました。

3月版から起動したインスタンスで更新前後の rpm -qa の一覧を比べると、パッケージ数は 476 から 497 に増えました。バージョンまで含めて比べると、更新前にだけあるパッケージが 174件、更新後にだけあるパッケージが 195件でした。user-data の開始から完了までは 93秒でした。ゲストから見えるメモリが約 910 MiB の t8i.micro でも、更新は完了しました。11月版から起動したインスタンスは、OS のリリースがすでに 2023.12.20261102 だったため、更新前後でパッケージに差分はありませんでした。

更新しただけでは旧カーネル 6.18.8 の rpm がディスクに残ります。これが後述のとおりスキャンの検出として残り続けるため、新カーネルで再起動したうえで旧カーネルを撤去する版も用意しました。新カーネル 6.18.56 で起動していることを確認してから、6.18.8 の rpm を削除します。

$ sudo reboot
# 再起動後、新カーネルで起動していることを確認
$ uname -r
6.18.56-125.164.amzn2023.x86_64
# 旧カーネル 6.18.8 の rpm をまとめて削除
$ sudo dnf remove -y $(rpm -qa 'kernel6.18*' | grep 6.18.8-9.213)
# 残るのは 6.18.56 系のみ
$ rpm -qa 'kernel6.18*' | sort
kernel6.18-6.18.56-125.164.amzn2023.x86_64
kernel6.18-tools-6.18.56-125.164.amzn2023.x86_64

更新したインスタンスと、旧カーネルを撤去したインスタンスから、それぞれ create-image で AMI を作成しました。

$ aws ec2 create-image --instance-id i-1234567890abcdef0 --name devio-al2023-old-updated-20261102
$ aws ec2 create-image --instance-id i-0abcdef1234567890 --name devio-al2023-old-updated-nooldkernel-20261102

検証結果

4つの AMI の検出件数

各値は、2026-11-03 に4つの AMI を1回ずつスキャンした結果です。

重大度別の件数は get-image-findings の集計です。所要時間は、get-on-demand-scan-status の startedAt と completedAt の差です。

3月版の3,161件をパッケージ別に集計しました。タイトルに複数のパッケージ名が並ぶ検出は、最初の名前で数えています（kernel6.18, kernel6.18-tools なら kernel6.18）。kernel6.18 が2,743件で、全体の約87%を占めました。

更新後に消えた検出と残った検出

3月版（更新後）では、更新前の3,161件のうち kernel6.18 以外の418件（critical 1、high 144、medium 230、low 43）がすべて消えました。critical の1件は amazon-ssm-agent です。更新後にだけ現れた検出はありませんでした。

残った2,743件は、すべて kernel6.18 の検出です。先頭の CVE / ALAS 番号で突き合わせると、3月版にあった kernel6.18 の検出と完全に一致し、1件も消えていません。これらはいずれも、ディスクに残った旧カーネル 6.18.8（kernel6.18 6.18.8-9.213.amzn2023）の rpm に対する検出です。

実行中のカーネルは更新で入った 6.18.56 ですが、AMI スキャンは起動状態ではなくディスク上のパッケージを見るため、使われていない旧カーネルの rpm も検出します。新カーネルで再起動したあと旧カーネル 6.18.8 の rpm を撤去し、作り直した AMI（3月版 更新後、旧カーネル撤去）をスキャンすると、検出は0件になりました。

結果の取得先と検出の項目

describe-images の ScanResults は AMI 全体のサマリで、3月版と11月版では、次の値が返りました。

$ aws ec2 describe-images --image-ids ami-0fedcba9876543210 ami-0123456789abcdef0 --query Images\[\].\{Id:ImageId\,Name:Name\,Scan:ScanResults\} --output json

[
    {
        "Id": "ami-0123456789abcdef0",
        "Name": "devio-al2023-new-20261102-copy",
        "Scan": {
            "FindingScanDate": "2026-11-03T03:03:15.821000+00:00"
        }
    },
    {
        "Id": "ami-0fedcba9876543210",
        "Name": "devio-al2023-old-20260302-copy",
        "Scan": {
            "HighestFindingSeverityLabel": "critical",
            "FindingScanDate": "2026-11-03T03:02:46.465000+00:00",
            "LowFixAvailableSince": "2026-11-03T03:07:22.728000+00:00",
            "MediumFixAvailableSince": "2026-11-03T03:07:22.728000+00:00",
            "HighFixAvailableSince": "2026-11-03T03:07:22.728000+00:00",
            "CriticalFixAvailableSince": "2026-11-03T03:07:22.751000+00:00"
        }
    }
]

HighestFindingSeverityLabel は、修正の有無にかかわらず、検出の中で最も高い重大度を示します。*FixAvailableSince は、Inspector がその AMI で修正ありと報告した最初の時刻です。ベンダーが修正を公開した日ではありません。

個別の検出は get-image-findings で取得します。3月版の critical の検出（amazon-ssm-agent）は、次のように返りました。該当する1件だけを抜粋しています。

$ aws ec2 get-image-findings --image-id ami-0fedcba9876543210

        {
            "FixAvailable": true,
            "Score": 9.9,
            "FirstObservedAt": "2026-11-03T03:07:22.751000+00:00",
            "UpdatedAt": "2026-11-03T03:07:22.751000+00:00",
            "Title": "CVE-2026-89049 - amazon-ssm-agent",
            "Paths": [
                "/var/lib/rpm/rpmdb.sqlite"
            ],
            "SeverityLabel": "critical",
            "SnapshotId": "snap-0123456789abcdef0"
        }

get-image-findings が返すのは修正の有無（FixAvailable、真偽値）までで、脆弱性の説明文や修正済みバージョンは含まれません。Inspector の詳細な検出レポートが必要な場合は、Amazon EventBridge の連携をお試しください。

https://docs.aws.amazon.com/inspector/latest/user/eventbridge-integration.html

まとめ

Amazon Inspector の AMI スキャンで、インスタンスを起動せずに AMI 内のパッケージの脆弱性を検出できることを確認できました。

ゴールデン AMI を作る EC2 Image Builder の後処理などに組み込めば、インスタンスを起動する前に、カーネルなどのパッケージが更新済みかを AMI の段階で確認できます。

ただ、既存の AMI を更新して使う場合は注意が必要でした。今回のように dnf upgrade でリリースをあげるだけでは誤検知が発生。解消には旧カーネルパッケージの削除が必要でした。

また、オンデマンドスキャンは1回ごとに課金され（東京リージョンで約0.51 USD）、無料トライアルの対象外であるため、コストにも留意してください。