はじめに
この記事を3行で
- InspectorはEC2を継続的にスキャンしているが、スキャン方式によって検出のタイムラグが変わる
- InspectorではOSパッケージで発生しやすいバックポートによる誤検知を抑制する仕組みとなっている
- Inspectorのスキャン範囲は決まっており、それ以外のパスをスキャンしたい場合はInspector Deep inspectionの利用が必要
想定読者
- 脆弱性についての基本知識はあり、Inspectorの詳細を知りたい人
- Inspectorを既に利用している/基本的な機能は知っていて、スキャンの仕組みを知りたい人
記事の目的
「AWSのエンドポイントセキュリティ、AWSサービスだけで実現できる？Inspector/GuardDutyとEDRの役割分担を整理してみた」をまとめるにあたり、EDRとInspectorの違いの解像度を高めるために、以下の項目についてInspectorの仕様を調査しました。
- 脆弱性検出までのタイムラグ
- 正確性（誤検知への対処）
- 網羅性（スキャンの対象範囲）
同様の疑問がある方のお役にたつと幸いです。
※出典元を明記している画像を除いて、本記事で使用している画像は生成AIによって生成した画像です。
Amazon Inspectorの機能概要
Amazon Inspectorは、AWS上のワークロードに対して自動/手動で脆弱性スキャンを行い、リスクを可視化するマネージドサービスです。対象リソース( * )に新しい脆弱性（CVE）が見つかると、ほぼリアルタイムに再評価を行い結果を通知します。
では、「ほぼリアルタイム」とはどれくらいなのか？Inspectorの誤検知や検知漏れはあるのか？といったことが気になったので調査しました。（いわゆるQCDのうちのQualityとDeliveryの部分）
*Amazon Inspectorがサポートするサービス
2025/12時点：Amazon Inspector とは
- Amazon EC2 インスタンス（ネットワークの露出も検知）
- Amazon ECR のコンテナイメージ
- Lambda 関数
Inspectorのスキャン方式（SSM Agent利用／EBSスナップショット取得）
InspectorではEC2にエージェントを導入しているかどうかによってスキャンの挙動が異なるため、スキャン方式を整理しておきます。
現在Inspectorでは、以下の2つのスキャン方式に対応しています。
-
エージェントベースのスキャン： System Manager Agent の利用
EC2にインストールされたSSM Agentとプラグインを使用して、EC2からソフトウェアインベントリを収集する -
エージェントレススキャン： EBSスナップショットを取得
Inspectorがバックグラウンドで取得したEBSスナップショットからソフトウェアインベントリを収集する
InspectorのEC2スキャンでは、EC2から収集したソフトウェアインベントリをInspectorのもつ脆弱性情報と比較しています。上記のスキャン方式によって、ソフトウェアインベントリを収集する方法とそのタイミングが異なります。
正確には、Inspectorのスキャンモードは「エージェントベースのスキャン」か「ハイブリッドスキャン」を指定します。
「ハイブリッドスキャン」はエージェントベース/エージェントレスによるスキャンを組み合わせたモードです。エージェントレススキャンのみを明示的に利用することはできません。 詳細は「公式ドキュメント」をご確認ください。
1.Inspectorによる脆弱性スキャンのタイムラグ
脆弱性が埋め込まれている場合、脆弱性を発見し対処するまでの時間が長くなるほど攻撃者にその「弱点」を悪用されるリスクが高まります。そのため、脆弱性スキャンツールの導入において検出スピードは重要なチェックポイントとなります。
現在最新のInspector v2では「継続的スキャン」が導入されていますが、実際にどのくらいのタイムラグで脆弱性が検知されるのでしょうか。公式ドキュメントから仕様を確認したところ、スキャン対象のリソース・イベントによってスキャンのタイミングは異なるようです。(さらにスキャン方式によってもタイムラグが異なります)
今回はEC2の場合にフォーカスして整理しました。EC2の場合、スキャンのトリガーとなるイベントは「初回」、「構成変更時」、「新規脆弱性（CVE）公開時」の3つになります。それぞれのイベントにおけるタイムラグは以下です。
| イベント | タイムラグ（目安） | スキャン方式 | スキャンのタイミング |
|---|---|---|---|
| ① 新規構築・起動 |
数分 〜 数十分 (SSM Agent起動の待機時間) |
SSM Agent | インスタンスが起動し、SSM Agentが「Online」になった時点 |
|
最大1時間 (固定の検出サイクル) |
エージェントレス | 定期 | |
|
② 構成変更 (ソフトインストール等) |
デフォルトで最大30分 (SSM Agentによるインベントリ収集間隔) |
SSM Agent | SSM Agentが「ソフトウェアインベントリの変更」を検知したらスキャン |
|
最大24時間 (1日1回の定期スキャン) |
エージェントレス | 定期 | |
|
③ 新規脆弱性（CVE）公開時 |
明確な情報なし | SSM Agent | 脆弱性情報がInspectorデータベースに反映されたタイミング |
|
最大24時間 (1日1回の定期スキャン) |
エージェントレス | 定期 |
それぞれのイベントとスキャンのタイミングについて解説します。
「初回」の脆弱性スキャン
新しいEC2が起動したとき、InspectorがそのEC2をスキャン対象として認識したタイミングで初回のスキャンが実施されます。
エージェントベースの場合はSSM Agentがオンラインになり、ソフトウェアインベントリの収集が可能になったタイミングでスキャンが開始されます。公式ドキュメントでは明確には示されていませんが、SSM Agentがオンラインになるまでの時間は数分～数十分レベルであると予想されます。必要なSSM Agentの設定については、公式ドキュメントをご確認ください。
エージェントレスの場合は、新しくスキャン対象となるEC2を1時間ごとに検出し、新しいEC2があった場合にスキャンします。「新しくスキャン対象」となるEC２は以下のものです
- SSM Agentがインストールされていない新しいEC2インスタンス
- ステータスが
SSM_UNMANAGEDに変更された既存のEC2インスタンス
「構成変更時」の脆弱性スキャン
既存のEC2に新しいソフトウェアをインストールした場合、その脆弱性を再検査する必要があります。Inspectorの場合、既存のEC2に対して以下のタイミングで再スキャンが実施されます。
- エージェントベースのスキャン：
SSM Agentは 「30分に1回（デフォルト）」,「最短5分に1回1」 の頻度でEC2のインベントリを評価
→ インベントリの変更が検出されるとスキャンを実行 - エージェントレス：
「24時間に1回」 の頻度で定期的にスキャンを実行
エージェントベースの場合、EC2へのスキャン間隔は変更することができます。スキャン間隔が長すぎると以下のようなリスクがあるため、デフォルトの設定をそのまま使うのではなく、適切なスキャン間隔を検討したうえで設定する必要があります。
リスクの例：
攻撃者が侵入し不正なツールをインストールして攻撃しても、30分以内に不正なツールを削除した場合、タイミングによってはInspectorで検知できない
「新規CVE公開時」の脆弱性スキャン
EC2側の変更だけでなく、Inspectorの脆弱性情報に変更があった場合にもスキャンが実行されます。つまり、世間で新しい脆弱性（CVE）が発見・公開されると自動でスキャンが実行されます。
スキャンの実行タイミングは以下となります。
- エージェントベースのスキャン：
新規CVEが公開されるとInspectorデータベースにその情報が追加され、EC2の再スキャンを実行 - エージェントレス：
「24時間に1回」 の頻度で定期的にスキャンを実行
→ Inspectorデータベースに変更があった場合、この定期スキャンのタイミングで新規CVEが検出される
エージェントベースについては、明確なタイムラグの情報は公開されていません。しかし、Inspectorのデータベースは少なくとも1日1回は更新されるため、エージェントレスの場合と同様に、最大でも24時間以内には検出されると考えられます。
2.Inspectorによる脆弱性スキャンの誤検知
セキュリティ製品では誤検知が多いと不要な調査工数が増え、運用負荷やビジネス影響が大きくなります。脆弱性スキャンの仕組みを踏まえて、その製品で誤検知がどの程度発生しやすいかを確認することが重要です。
特に誤検知の原因となりやすい「バックポート」について、どのように評価しているか確認しておきましょう。
バックポート（backport）とは
LinuxディストリビューションではOSの安定性を最優先するため、メジャーバージョンを更新せずに セキュリティ修正のみを既存バージョンへ移植（backport） する運用が採用されており、これを「バックポート」と呼びます。つまり、バージョン番号が古いままでも、最新のパッチが適用されているケースが多く存在しています。
そのため、パッケージ名・バージョン番号だけに基づいて脆弱性を判定すると、実際にはパッチ適用済みであっても“脆弱性あり” と誤検知されてしまいます。一般的に、この誤検知を抑制するアプロ―チとして以下があります。
- OSベンダーが提供するバックポートパッチを適用したパッケージ情報(OVAL等)を利用
- パッケージ管理ツールのchangelogを確認
Inspectorの仕様
Inspectorでは以下の通り、ベンダーのセキュリティアドバイザリを含む50以上のデータソースをもとにCVEの判定を行っています。
Inspectorが参照するソースの例：
- ベンダーのセキュリティアドバイザリ
- 脅威インテリジェンスフィード
- 国家脆弱性データベース (NVD)
- MITRE
そのため、単純なバージョン比較のみを行っている場合に発生しやすいバックポート関連の誤検知は起きにくいと考えられます。一方で各プログラミング言語のライブラリについては、バックポートのような標準的な管理手法がありません。単純なバージョン比較のみで脆弱性の判定をするため、OSパッケージと比較すると誤検知は起こりやすいことがあります。
3.Inspectorによる脆弱性スキャンの対象範囲
スキャン時間の増加やOSへの負荷を考慮して、一般的に脆弱性スキャンではOSのファイルシステム全領域をスキャンすることはありません。製品によってスキャンする範囲が異なるため、どこまでがスキャン対象の範囲なのかも製品選定のポイントとなります。
Inspectorがスキャンするパス
Inspectorの場合、「OSパッケージ」と「プログラミング言語パッケージ」はどちらのスキャン方式(エージェントベース/エージェントレス)でもスキャンされます。具体的には、以下の「デフォルトパス」がスキャン対象となります。
/usr/lib/usr/lib64/usr/local/lib/usr/local/lib64
スキャン方式による大きな違いとしてDeep inspectionの利用可否があり、Deep inspectionはエージェントベーススキャンでのみサポートされます。Deep inspectionでは「カスタムパス」として、デフォルトパス以外の任意のパスをスキャン対象に含めることができます。
Inspectorのスキャン範囲
- Inspectorでは特定のファイルパスがスキャン対象
- エージェントベース方式の場合、任意のパスをスキャン対象に追加可能
Inspectorのスキャン範囲に関する考慮事項
InspectorのEC2スキャンでは、デフォルトのパッケージマネージャーリポジトリ（rpm/dpkg）のみをサポートしているため、パッケージマネージャーを使わずにインストールしたパッケージは検出されません。
これらの対策として、以下が考えられます。
- CI/CDパイプラインの利用による手動インストールの禁止
- SCA（Software Composition Analysis）ツールの併用
Amazon Inspector EC2スキャン機能まとめ
Inspectorによる脆弱性スキャンについて、以下の3つの観点で仕様を調査しました。
-
脆弱性検出までのタイムラグ
- スキャン方式によってタイムラグは異なり、より高いリアルタイム性を求める場合はエージェントベース方式を利用する必要がある
- 新しく公開されたCVEも自動で検出されるが、外部ソースからInspectorデータベースに反映されるまでのタイムラグは発生する
-
正確性（誤検知への対処）
- OSパッケージで起こりがちなバックポートによる誤検知については、OSベンダーからのデータも参照することで抑制する仕組みとなっている
-
網羅性（スキャンの対象範囲）
- スキャンするファイルパスは決まっている
- エージェントベース方式の場合、「カスタムパス」として任意のパスをスキャン対象に追加可能
タイムラグや網羅性（スキャンの対象範囲のカスタマイズ性）の観点から、スキャン方式としてエージェントベースを採用するメリットが多いことが分かりました。
関連記事
本調査の発端：
AWSのエンドポイントセキュリティ、AWSサービスだけで実現できる？Inspector/GuardDutyとEDRの役割分担を整理してみた
機能詳細GuardDutyバージョン：
coming soon
参照したドキュメント
-
Cron expressions that lead to rates faster than five (5) minute aren't supported.
出典: Cron and rate expressions for associations ↩