2026年11月、AWS は AWS Security Hub が、コンピューティングリソースの SBOM（ソフトウェア部品表）インベントリを提供するようになったと発表しました。セキュリティを見るチームが、組織全体のコンピューティングリソースにどのソフトウェアパッケージが入っているかを、継続的に更新される一つのビューで把握できるようになります。
本記事は、AWS のセキュリティを運用する人に向けて、この発表が「仕組みとして何を変えたか」「自分の案件で何に使えるか」を整理するニュース記事です。クラウド全体の入口は「AWS とは」、守りの土台は「アカウントのセキュリティ」にまとめています。
この記事の結論
- Security Hub が、Amazon Inspector の SBOM を材料に、組織横断の「パッケージ棚卸し」を自動で見せるようになった（EC2・ECR・Lambda が対象）。
- 新しい有効化も追加費用も不要で、Security Hub Essentials に含まれ、Inspector が有効な場所に自動で反映される。
- いちばんの効きどころは、脆弱性が出たとき「どこに影響するか」を手集計から検索に変えられること。画面でも Security Hub API でもたどれる。
- ただし SBOM は「何が入っているか」。脆弱性の有無は Inspector の検出結果と合わせて見る。反映に数時間かかることがあるので、瞬時の在庫確認用途には向かない。
何が起きたか
Security Hub が、Amazon Inspector の SBOM を材料に、パッケージ単位の在庫（インベントリ）を作って見せるようになりました。発表の要点はこうです。
・対象：Amazon Inspector が Amazon EC2 インスタンス・Amazon ECR コンテナイメージ・AWS Lambda 関数に対して生成する SBOM から構築する（追加の設定は不要）
・見え方：SBOM ページに、各パッケージがバージョン・タイプ・インストールされているリソース数とともに一覧される。パッケージ属性・アカウント・リージョンでフィルターやグループ化ができる
・リソース単位：リソース詳細ページの「インストール済みソフトウェア」タブで、そのリソース上のすべてのパッケージを確認できる
・プログラムから：Security Hub API 経由でインベントリをクエリできる
・費用と範囲：Security Hub Essentials に含まれ追加費用なし。新たな有効化は不要で、Inspector が有効な場所に自動で反映され、Security Hub が使える全リージョンで利用できる
くわしくは公式の発表（本記事末尾の参照ソース）で確認してください。
仕組みとして何が変わったか
これまでも Amazon Inspector は、個々のリソースに対して SBOM を生成していました。足りなかったのは、「どのパッケージが、組織のどこに、何個入っているか」を横断で見る統合ビューです。脆弱性が公表されたとき、「自分たちの環境のどこに、その影響を受けるパッケージがあるか」を知るには、リソースごとの情報を手でかき集めて数える必要がありました。
BEFORE / AFTER何が変わったか
リソースごとの SBOM から、組織横断のパッケージ棚卸しへ
これまで
- Inspector が各リソースの SBOM を生成
- 「どのパッケージがどこに何個あるか」は横断で見づらい
- 脆弱性対応の優先度は手で集計して判断
- パッケージ単位の一覧・絞り込みが無い
これから
- Security Hub が Inspector の SBOM からインベントリを自動構築
- パッケージ単位（バージョン・タイプ・導入数）で一覧
- 属性・アカウント・リージョンで絞り込み/グループ化
- Security Hub API でもクエリできる
今回の変更で、その棚卸しを Security Hub が肩代わりします。Inspector が各リソースに対して出していた SBOM を Security Hub が集約し、パッケージを主役にした一覧へ組み直します。「このバージョンのこのライブラリが、どのアカウント・どのリージョンの何個のリソースに入っているか」を、画面でもAPIでもたどれます。
動いたのは「集計の責任」です。これまで利用者側が手で組んでいた「パッケージ横断の棚卸し」を、設定を増やさずにサービスへ寄せられるようになりました。一方で、何を直すか・いつ直すかの判断や、Inspector を有効にしておくことは、引き続き利用者側の仕事です。
CHECK 1ここまでの確認
今回 Security Hub が提供するようになった SBOM インベントリは、何から作られる?
答えと解説
答え: 2. Amazon Inspector が EC2・ECR・Lambda 向けに生成する SBOM
Security Hub は、Amazon Inspector が EC2 インスタンス・ECR コンテナイメージ・Lambda 関数に対して生成する SBOM から、パッケージ単位のインベントリを組み立てます。手での登録は不要で、CloudWatch のメトリクスとは別物です。「仕組みとして何が変わったか」の節を読み直してください。
どんなものに活用できそうか
HOW IT IS BUILTデータの流れ
Inspector のスキャンが、そのまま組織の棚卸しになる
-
Inspector がスキャン
EC2 インスタンス・ECR コンテナイメージ・Lambda 関数を Amazon Inspector がスキャンし、各リソースの SBOM を生成
-
Security Hub が集約
Inspector が有効な場所の SBOM を Security Hub が自動で取り込み、パッケージ単位のインベントリに組み直す（追加の有効化は不要）
-
棚卸し・優先度づけ
SBOM ページで一覧・絞り込み、リソース詳細の「インストール済みソフトウェア」でそのリソースの全パッケージを確認。どの検出から直すかの判断材料にする
実務では、こんな場面に当てはめられます。
・「影響を受けるのはどこか」を即答する：あるライブラリに重大な脆弱性が出たとき、その名前とバージョンでインベントリを絞り込み、該当リソースの数と場所を把握する。調査の初動が、手集計から検索に変わる
・対応の優先度をつける：リソース詳細の「インストール済みソフトウェア」で、その資産が何をしているか・どれだけ重要かを踏まえ、どの検出（フィンディング）から直すかを決める
・組織横断の可視化を自動化する：Security Hub API でインベントリをクエリし、特定パッケージの分布を定期的に棚卸しする仕組みを作る
一方、使い方を誤らない方がよい場面もあります。これは「継続的に更新される棚卸し」であって、瞬時の在庫確認ではありません。Inspector のスキャンから反映まで数時間かかることがあるため、「いま一斉に消えたか」をリアルタイムに保証する用途には向きません。また、SBOM は何が入っているかを示すもので、脆弱性の有無そのものは Inspector の検出結果と合わせて見る必要があります。
CHECK 2ここまでの確認
この SBOM インベントリを使うための前提として、正しいものはどれ?
答えと解説
答え: 1. 対象のリソース種別で Amazon Inspector が有効になっていること
SBOM インベントリは Security Hub Essentials に含まれ追加費用はかからず、新たな有効化も要りません。ただし中身は Inspector のスキャン結果から作られるため、対象のリソース種別で Inspector が有効である必要があります。エージェントは不要です。「どんなものに活用できそうか」の節を読み直してください。
立場ごとに何が変わるか
・未経験：いまは直接の関わりは薄いです。理由は、棚卸しの対象になるリソースをまだ運用していないから。ただ「SBOM＝ソフトウェアの部品リスト」という言葉だけ押さえておくと、あとで効きます
・学習中：「Inspector が脆弱性を見つける」「SBOM で何が入っているかを把握する」という役割の違いを、用語として押さえる段階です
・実務：直接効きます。Inspector を有効にしていれば、追加作業なしで組織横断の棚卸しが手に入ります。脆弱性対応の初動と優先度づけが速くなります
・プロ：アカウント・リージョンをまたいだガバナンスに使えます。API で分布の棚卸しを自動化し、サプライチェーンの可視性を運用に組み込めます
試験との関係では、AWS Certified Security - Specialty（SCS）の、ログと監視・脆弱性管理の領域に近いテーマです。SBOM と Inspector・Security Hub の役割分担を、言葉で説明できるようにしておくと役立ちます。
まとめ
Security Hub の SBOM インベントリは、Inspector がすでに作っていた SBOM を、組織横断の「パッケージの棚卸し」として見せ直す機能です。新しい有効化も追加費用もなく、Inspector が有効な場所に自動で反映されます。脆弱性が出たときに「どこに影響するか」を手集計から検索に変えられるのが、いちばんの実務的な効きどころです。反映に数時間かかること、脆弱性の判定は検出結果と合わせて見ることだけ、運用の前提として押さえておきましょう。
