Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Amazon Inspector概論
Search
Masedati
April 18, 2026
150
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Amazon Inspector概論
Masedati
April 18, 2026
More Decks by Masedati
See All by Masedati
CUDOSを構築しよう
masedati
0
22
CPUクレジット使われた話
masedati
0
29
内製化支援で伝えている AWSネットワークとEC2への接続方法
masedati
0
19
Amazon Q CLIの歩き方
masedati
0
92
改めて学ぶデプロイ戦略
masedati
0
29
怠惰な人のためのブログ執筆術
masedati
0
13
AWS リソース使用前に料金体系はしっかり確認しよう
masedati
0
14
【Amazon Bedrock】存在しないヒエログリフを作りたい
masedati
0
13
Hey、Polly。大事な話があるんだけど
masedati
0
14
Featured
See All Featured
The Hidden Cost of Media on the Web [PixelPalooza 2025]
tammyeverts
2
330
Claude Code のすすめ
schroneko
67
230k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.7k
Getting science done with accelerated Python computing platforms
jacobtomlinson
2
220
We Are The Robots
honzajavorek
0
250
The Cost Of JavaScript in 2023
addyosmani
55
10k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.5k
A Modern Web Designer's Workflow
chriscoyier
698
190k
Design in an AI World
tapps
1
240
[RailsConf 2023] Rails as a piece of cake
palkan
59
6.7k
Evolving SEO for Evolving Search Engines
ryanjones
0
220
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
133
19k
Transcript
Amazon Inspector概論
本日お話しすること 初心者向けAmazon Inspector v2講座 ❌ Inspector Classicについて ・どのようなものか? ・仕組み ・運用フロー
Inspector Classicは、2026年5月20日にサポートが終了しました。 スキャン対象や必要なエージェント等v2と細かな違いがあります。
自動的かつ継続的にAWSリソースの脆弱性検知を行う Inspectorとは? EC2, ECR, Lambdaを自動的に検出し、ソフトウェアの脆弱性や 意図しないネットワーク露出がないかを継続的にスキャンします。 脆弱性が検出されるとレポートを生成します。 🔍スキャン対象
自動的かつ継続的にAWSリソースの脆弱性検知を行う Inspectorとは? EC2, ECR, Lambdaを自動的に検出し、ソフトウェアの脆弱性や 意図しないネットワーク露出がないかを継続的にスキャンします。 脆弱性が検出されるとレポートを生成します。 🔍スキャン対象
脆弱性“診断”ではないの? 脆弱性検知と脆弱性診断
脆弱性検知と脆弱性診断 ※人によって考え方は違います ◆脆弱性検知 すでに見つかっている脆弱性が自分のシステムに存在しないか効率的に チェックをすること ex. Amazon Inspector ◆脆弱性診断 自分のシステム全体にどのようなリスクがあるか専門家・専門ツールが総
合的に評価するプロジェクトもしくはソフトウェア ex. ペネトレーションテスト
AWSサービスで脆弱性“診断”できないの? 脆弱性検知と脆弱性診断 Security Agentで(一部)できるよ!
AWS Security Agent AWS re:Invent 2025で発表された新しいセキュリティサービス AI駆動のセキュリティエージェントサービスです。 ◆設計ドキュメントレビュー ◆ソースコードやプルリクエストに対するコード分析 ◆ペネトレーションテスト
・AIエージェントがアプリケーション構成や実装内容を理解 ・従来のスキャンツールでは検出できない脆弱性を検出 ・影響分析やコード修正を含むプルリクエストを作成できる
Inspectorで既知の脆弱性を継続的に検知しつつ、 Security Agentで診断するのが理想的な組み合わせ これからの脆弱性管理
脆弱性の事例 2025年12月に公開されたReactの脆弱性(CVSS 10.0) ◆具体的には? クライアント(ブラウザ)とサーバー間のデータをやり取りするための プロトコル「React Flight」の脆弱性 ◆簡単に言うと 攻撃者が細工したHTTPリクエストをサーバーに送信し、検証なく実行さ れることで任意コードの実行が可能に。
React2Shell 脆弱性 (CVE-2025-55182) に対する中国関連脅威アクターの活発な悪用活動
CVEとCVSSとは ◆CVE(Common Vulnerabilities and Exposures) ・公開された情報セキュリティの共通脆弱性識別子 ・米国政府の支援を受けた非営利団体のMitre Corporationが管理 ・CVE-年-番号 ◆CVSSとは
・脆弱性の深刻度を数値化するための業界標準スコアリングシステム ・0.0:None ・0.1~3.9:Low ・4.0~6.9:Medium ・7.0~8.9:High ・9.0~10.0:Critical
自動的かつ継続的にAWSリソースの脆弱性検知を行う Inspectorとは?(再掲) EC2, ECR, Lambdaを自動的に検出し、ソフトウェアの脆弱性や 意図しないネットワーク露出がないかを継続的にスキャンします。 脆弱性が検出されるとレポートを生成します。 🔍スキャン対象
検出結果のタイプ ◆パッケージの脆弱性 EC2, ECR, Lambdaにインストールされているソフトウェアパッケージを 既知のCVEと照合して脆弱性を検出する ◆ネットワーク到達性 EC2に対して、TCP/UDPポートへのオープンなネットワークパスが存在す るか検出する ・HTTP(80番ポート)
: インターネット経由ならLow, それ以外ならInfo ・SSH(22番ポート) : インターネット経由ならMedium, それ以外ならLow
EC2のスキャン EC2スキャンには2つの方式があります。 ◆エージェントベース SSM Agentによりインベントリ収集し、スキャン スキャン頻度: ・新しいEC2を起動したとき ・Linux: 新しいソフトウェアをインストールしたとき Inspectorが新しいCVEを追加したとき
・Windows:6時間ごと ◆🆕エージェントレス EBSのスナップショット作成→スキャン→スナップショット削除 スキャン頻度:1時間ごとに新しいEC2を検出・スキャン→24時間ごと
ECRのスキャン OSパッケージの脆弱性やプログラム言語の脆弱性を検出します。 スキャン頻度: ・コンテナイメージがプッシュされたとき ・プッシュ後に新しいCVEが公開されたとき
Lambdaのスキャン ◆スキャン内容 ・パッケージの脆弱性 ・コード脆弱性 ◆スキャン頻度 ・新しいLamda関数をデプロイしたとき ・既存関数のコードの更新時 ・Inspectorが新しいCVEを追加したとき
import requests # ← 依存パッケージ import boto3 # ← 依存パッケージ
def handler(event, context): user_input = event["query"] # SQLインジェクションの可能性 → Lambdaコードスキャンが検出 query = f"SELECT * FROM users WHERE name = '{user_input}'" # requestsライブラリ自体にCVEがあれば # 「アプリケーションパッケージの脆弱性」 → Lambda標準スキャンが検出 response = requests.get("https://api.example.com") return {"statusCode": 200} パッケージとコード脆弱性の違い
検知したらどうするの? ◆前提 ・通知設定を行う ・通知疲れしてしまうので、全てを通知する必要はない ex. Critical, Highのみ通知して、その他は月1回の定例で確認する
検知したらどうするの? 1.スコアを評価し、優先度を決める 2.対応方針決定 ・検証環境でパッチ適用など検証 →アプリケーション側に不具合がでる可能性やパッチ適用失敗する可能性 ・本番でどのパッチを適用するか等検討 3.修復 ・パッチ適用 ・ECRイメージの再ビルド、再プッシュ ・Lambdaのパッケージ更新、コード修正
4. Inspectorで検出結果がクローズとなったことを確認
可能なら自動化を ◆InspectorのFindingをSecurity Hub → EventBridge経由でSSM Automationに連携し、対 象パッケージを特定してパッチ対象リストをS3に作成 ◆SSM Run Command(AWS-RunPatchBaseline)がそのリストを使い、Finding起因のパッ
ケージだけにピンポイントでパッチを適用 ◆パッチ適用後にインベントリを即時再収集し、Inspectorが再評価してFindingを自動クローズ Amazon Inspector と AWS Systems Manager を用いて脆弱性の修復パイプラインを構築しよう - builders.flash☆ - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
本日学んだこと Inspectorで脆弱性検知しよう! どれを通知するか考えよう! 検知時の対応をあらかじめ決めておこう!