こんにちは、セキュリティエンジニアの田所です。
先日参加してきた AWS Summit Japan 2026 からセッションの模様をお届けします。

セッションについて

SEC337 一歩先を行く：効果的な脆弱性管理のためのスマート戦略

従来型の脆弱性管理では、定期スキャンによる検出の遅れ、動的リソースの把握困難、膨大な検出結果の優先順位付けといった課題がつきものでした。本セッションでは、これらの課題を解決する Amazon Inspector を中心に、効果的な脆弱性管理を実現するスマートな戦略を解説します。組織全体でのニアリアルタイム継続スキャン、独自スコアリングによる優先順位付け、EC2・Lambda・ECR それぞれのスキャン機能の活用方法をデモを交えてご紹介します。さらに、GitHub／GitLab とネイティブ統合するコードセキュリティ機能により、開発ライフサイクルの早期段階で脆弱性を検出する「シフトレフト」戦略についても、デモを交えて解説します。

脆弱性管理を「定期的なもの」から「継続的な仕組み」へ変えていく、という戦略を Amazon Inspector を軸に解説するブレイクアウトセッションでした。

1. Amazon Inspector の機能

従来型の脆弱性管理には、以下のような課題が付きまといます。

  • 脆弱性スキャンが時間による環境変化に追従できない
  • 全リソース、全コードを網羅できない
  • リリース直前までセキュリティチェックが行われない

また脆弱性スキャンは定期実行するケースが多いと思いますが、検出の遅れ、動的リソースの取りこぼし、膨大な検出結果の毎回の仕分け、に悩まされることもありがちです。

こうした課題に応えるのが Amazon Inspector です。
ソフトウェアの脆弱性や意図しないネットワークへの露出を継続的に監視する、自動化された脆弱性管理サービスです。
数クリックでリソースの把握を開始し、継続的なスキャンと脆弱性データベースの維持管理、ニアリアルタイムの検出通知までを担います。
検出結果はリスクスコアでコンテキスト化され、Security Hub や EventBridge と連携してアクションの自動化にもつなげられます。

最初のステップは、有効化と組織全体の可視化です。
AWS Organizations と連携すれば、マルチアカウント環境でも委任管理アカウントから 1 クリックで全アカウントに有効化でき、新規アカウントの自動有効化も可能です。

またスキャンはイベントドリブンで動きます。
新しい CVE の公開や、パッケージのインストール、パッチの適用といったタイミングを契機に、ニアリアルタイムで検出できる仕組みです。

検出された脆弱性は、メタデータと環境要因を関連付けたリスクスコアで優先順位付けされます。
裏側では脅威インテリジェンスが動いており、インスタンスのネットワーク露出や既知の攻撃コードの観測日まで加味されます。
AWS が環境を踏まえた独自のスコアを付けてくれる分、より精度の高い優先順位付けができるのは利点です。

その一方で、同じ CVE でも CVSS のスコアと Inspector の独自スコアには差が出ます。
スライドの例では CVSS が 8.8、Inspector が 7.8 となっていました。
SIer としてお客様に説明する立場だと、この差をどう伝えきるか悩ましい場面もありそうだとは感じました。

2. 継続的スキャンとアドホックスキャン

Inspector のスキャンは、継続的スキャンと アドホック (単発) なスキャン に大きく分かれます。
継続的スキャン は EC2・Lambda・ECR を対象とし、アドホック には SBOM 管理や CIS スキャン、CI/CD 統合が用意されています。

EC2 スキャン では、「全インスタンスを把握できていない」「野良インスタンスがありそう」といった悩みに応える機能が紹介されました。
SSM エージェントを利用したスキャンに加え、EBS スナップショットを読むエージェントレススキャンを組み合わせるハイブリッドモードで、管理漏れを防ぎます。

Lambda スキャン は、OS がない分意識が向きにくいという声を踏まえ、パッケージとコードのスキャンを組み合わせて実行できます。

ECR イメージスキャン は、基本のスキャンに Inspector の拡張スキャンを重ねられます。

アドホックなスキャン は、SBOM のエクスポートやスキャン、CIS ベンチマークに沿ったスキャン、Jenkins や TeamCity との CI/CD 統合に対応します。

3. コードセキュリティ

後半は、開発の早い段階からセキュリティを組み込む「シフトレフト」の話です。
Apache Log4j の脆弱性 (CVE-2021-44228) はセキュリティ界隈では非常に有名ですが、Log4j を利用するアプリケーションの 30% が、脆弱性のあるライブラリのまま使われ続けているというデータが示されました。
こういった事態を防ぐためには、開発段階からセキュリティチェックを行うことが有効な打ち手となります。

Amazon Inspector Code Security は、安全なサプライチェーン・安全なコード・安全なインフラの 3 つをカバーします。
具体的には以下の 3 つです。

  • コンポーネントやその依存関係の脆弱性を特定する SCA スキャン
  • リポジトリのコードの問題を検出する SAST スキャン
  • インフラの設定ミスを特定する IaC スキャン

また目指す姿として、次のようなガバナンスモデルが示されました。
セキュリティチームはガードレールを敷いてリポジトリ全体のリスクを把握し、開発者はそのガードレールの中でこれまで通り自由に開発する、という役割分担です。
Amazon Inspector にはそれを実現するための機能が備わっていると言えます。

まとめ

脆弱性管理を「定期」から「継続」へ変えるスマートな戦略を、Amazon Inspector の機能、継続的スキャンとアドホックスキャン、コードセキュリティ の3つの観点から見てきました。

先を行く脆弱性管理とは、クラウドの速度に対応した脆弱性管理を実現できていること、というメッセージが一貫していました。
継続的なスキャンでの検知、カバレッジの把握とリソース内の脆弱性の検知、そして開発段階での脅威の特定。
「開発者体験を損なうことなく、セキュアであることを当たり前にしたい。そのために Amazon Inspector が生まれた」という締めくくりが印象的でした。

脆弱性管理を「定期」から「継続」へ、という発想は、Inspector に限らず運用設計の軸として持っておきたいものです。
その上で SIer としては、スコアの考え方や対象範囲といった Inspector の特性まで理解し、お客様に合った形で提案・適用できることが価値になりそうだと感じました。

おしまい