こんにちは。AI LabチームのHan Kil Roです。サービスに必要なAIモデルやソリューションを開発するチームで業務に携わっています。最近、LINEヤフー社内で実施された Orchestrati...

本ブログは 2026 年 4 月 7 日に公開された AWS Blog “ Building AI defenses at scale: Before the threats emerge ” を翻訳したものです。 AWS は数十年にわたり、世界中で事業を展開する何百万のお客様を同時に保護するためのプロセスとツールを開発してきました。AWS のセキュリティチームと脅威インテリジェンスチームは、日々、表に出ることのない AI と自動化を駆使した取り組みを続けています。AI を活用したログ分析システムにより、SecOps エンジニアのセキュリティログ分析に要する時間は平均 6 時間からわずか 7 分にまで短縮されました。この 50 倍もの生産性向上により、脅威の検出と対応をかつてないスピードで行えるようになっています。AWS 全体では、1 日あたり 400 兆を超えるネットワークフローを分析し、新たな脅威の兆候となるパターンを検出しています。2025 年だけでも、Amazon S3 上のお客様のファイルを不正に暗号化しようとする 3 億件を超える試みをブロックしました。 あるお客様を保護する過程で得た知見は、すべてのお客様の保護に役立ちます。この規模で運用しているからこそ、新たに検出した脅威がすべてのお客様の防御強化に直結します。AI はすでにその中核を担っています。 サイバーセキュリティのための新たなクラスの AI 本日 (2026 年 4 月 7 日)、 Anthropic が Project Glasswing を発表しました 。これは、世界で最も重要なソフトウェアの保護と、AI の進化に伴い業界に求められるサイバーセキュリティの実践を前進させることを目的としたイニシアチブです。重要なデジタルインフラストラクチャを構築・運用する組織は、世界が依存するシステムの脆弱性を発見し修正するための新しいクラスの AI モデルである Claude Mythos Preview に早期アクセスできるようになります。世界で最も重要なインフラストラクチャの一端を保護する役割を担う AWS は、この取り組みを推進するうえで重要な役割を果たしています。 このプロジェクトを支えるのは、Anthropic のこれまでで最も高度な AI モデルであり、サイバーセキュリティにおける推論能力と AI 能力の飛躍的な進歩を実現する Claude Mythos Preview です。Claude Mythos Preview は根本的に新しいモデルクラスであり、Anthropic のこれまでのフロンティアモデルを上回る知性と能力を備え、サイバーセキュリティ、ソフトウェアコーディング、複雑な推論タスクでより高いパフォーマンスを発揮します。 Project Glasswing の一環として、AWS では継続的な AI セキュリティレビューが行われている重要なコードベースに Claude Mythos Preview をすでに適用しています。十分にテストされた環境であっても、コードをさらに強化できる箇所の特定に役立っています。内部テストでは、Claude Mythos Preview がセキュリティの検出結果を洗い出す際に従来のモデルよりも高い生産性を発揮し、エンジニアによる手動のガイダンスが少なくても実用的な結果を提供できることが実証されました。一部のお客様にも早期アクセスを提供しており、自社のセキュリティワークフローへの Claude Mythos Preview の導入を通じて、モデルの進化の方向性を形作ることに貢献しています。AWS にとって Claude Mythos Preview は、すでに活用している AI ツールの自然な進化形です。テクノロジーがより強力になるにつれて、防御もそれに合わせて強化していかなければなりません。 こうしたイノベーションこそが AWS の取り組みを推進するものであり、Claude Mythos Preview がエンタープライズでの利用に対応できるよう Anthropic と緊密に連携してきました。AWS は、Anthropic のミッションクリティカルなワークロードや安全性の研究、基盤モデル開発を支える主要なクラウドプロバイダーです。より広い視点で見ると、世界をリードする AI 企業が最先端モデルの構築、トレーニング、デプロイに利用する基盤インフラストラクチャを AWS が提供しています。数十年にわたるセキュリティの経験をこのパートナーシップに活かし、さらに多くの組織が Claude Mythos Preview を基盤として安全かつ大規模に運用できるよう支援しています。 Claude Mythos Preview は、これまでにないスケールと速度で脆弱性を発見し、実際に機能するエクスプロイトを構築できる新世代モデルの先駆けです。Anthropic と AWS は意図的に慎重なリリースアプローチをとっています。まず少数の組織からアクセスを開始し、数億人のユーザーに影響を与えるソフトウェアやデジタルサービスを提供するインターネットの重要インフラ企業やオープンソースのメンテナーが優先されます。目標は、世界で最も重要なソフトウェアの脆弱性を発見し修正することです。Claude Mythos Preview は Amazon Bedrock を通じて限定 (リサーチ) プレビューとして利用可能で、カスタマーマネージド暗号化、VPC 分離、詳細なログ記録などのエンタープライズグレードのセキュリティコントロールを備えています。これにより、本番環境のアセットを不要なリスクにさらすことなく、Claude Mythos Preview の機能を検証できます。 セキュリティを中核に据えた AWS のサービス設計 Project Glasswing における AWS の取り組みは、ミッションクリティカルなワークロードを 20 年以上にわたって保護してきた経験の中で培った理念に基づいています。脅威が現実化してから防御を構築するのでは遅いのです。先を見越して新しいテクノロジーを採用し、まず保護策を構築して自社の運用に大規模にデプロイし、そこから得た知見に基づいて改善を重ねていく必要があります。 これこそが AWS が AI とセキュリティにおいて実践してきたことです。AWS のアプローチは多岐にわたります。脅威ハンティングと脆弱性リサーチによるプロアクティブな防御、進行中の攻撃キャンペーンへの動的な対応、そしてセキュリティの取り組みが業界最高水準を満たすことを検証する第三者認証です。こうした運用経験から、AI がセキュリティ業務をどこで加速させ、人間の判断がどこで不可欠なのかを学びました。また、セキュリティのイノベーションは実用的でなければならない、つまりお客様にご活用いただく前に本番環境で実証されている必要があるということを改めて実感しました。 だからこそ AWS は、安全な AI とはどうあるべきかを定義する取り組みにも貢献しています。AWS は AI サービスにおける ISO 42001 認証を取得した最初の主要クラウドプロバイダーとなりました。OWASP、Coalition for Secure AI、Frontier Model Safety Framework にも積極的に参加しています。また、エコシステム全体でのより優れた脅威インテリジェンスの共有を実現するため、Open Cybersecurity Schema Framework (OCSF) を共同設立しました。 AWS Nitro System はワークロード間の数学的に証明された分離を実現します。ゼロオペレータアクセスアーキテクチャにより、AWS のオペレーターがお客様のデータにアクセスすることはできません。これらは将来の理想像ではなく、AWS が現在、大規模に日々実践していることです。 Amazon Bedrock は、これらの原則を AI の領域で実現するサービスです。ポリシー適用型のアクセス制御、モデルによる脆弱性の特定・検証の有効性を測定する組み込みの評価ツール、お客様専用の仮想プライベートクラウド内でワークロードを実行する機能を提供します。さらに AWS は、一般提供されている Claude 基盤モデルについて FedRAMP High および Department of Defense Security Requirements Guide Impact Level 4/5 の認定を取得した最初のクラウドプロバイダーでもあります。最も厳しいセキュリティ要件を持つ組織が、Anthropic のテクノロジーを安心して利用できる場として Amazon Bedrock を選んでいることの証です。 今すぐ始めるには AWS の大規模運用を支える原則は、使用する AI ツールに関係なく適用できます。包括的なオブザーバビリティ、多層防御、価値を生む領域での自動化、そして不可欠な場面での人間の判断です。以下にその実践方法をご紹介します。 次世代の AI セキュリティに備える。 Claude Mythos Preview は、サイバーセキュリティを変革する新世代の AI モデルの先駆けとなるものです。これらの機能がより広く利用可能になったときに備えて、今からセキュリティポスチャの強化を始めてください。Claude Mythos Preview は Amazon Bedrock を通じた限定プレビューとして利用可能であり、アクセスは許可リストに登録された初期の組織に限定されています。許可リストに登録されている場合は、AWS アカウントチームから直接ご連絡します。 AWS Security Agent でオンデマンドのペネトレーションテストを実行する。 一般提供が開始された AWS Security Agent は、手動のペネトレーションテストと比べてわずかなコストで 24 時間 365 日稼働する自律型ペネトレーションテストを提供します。ペネトレーションテストを、定期的に発生するボトルネックから、AWS、Azure、GCP、その他のクラウドプロバイダー、オンプレミスにわたり開発速度に合わせてスケールするオンデマンド機能へと変革します。AWS Security Agent は新しいクラスのフロンティアエージェントです。目標達成のために自律的に動作し、同時並行のタスクに対応するためにスケールし、人間の常時監視なしに継続的に稼働します。高度な多段階の攻撃シナリオを通じてセキュリティの脆弱性を発見、検証、報告する専門的な AI エージェントをデプロイします。検証なしに検出結果を生成する従来のスキャナとは異なり、AWS Security Agent は潜在的な脆弱性を特定した後、標的を絞ったペイロードと攻撃チェーンを使用してエクスプロイトを試み、正当なセキュリティリスクであることを確認します。各検出結果には、CVSS リスクスコア、アプリケーション固有の重大度評価、詳細な再現手順、修正の提案が含まれます。その結果、かつて数週間かかっていたペネトレーションテストが数時間で完了し、最も重要なシステムだけでなくアプリケーションポートフォリオ全体にわたってセキュリティカバレッジをスケールできるようになります。新規のお客様は 2 か月間の無料トライアルで AWS Security Agent をお試しいただけます。 Amazon Bedrock で信頼できる AI アプリケーションを構築する。 生成 AI を活用して構築するチームにとっての課題は、AI を機能させることだけではなく、AI を安全に機能させることです。Amazon Bedrock は、責任ある AI のデプロイに必要なセキュリティと安全性のコントロールを提供します。 自動推論 は、形式的論理を使用してハルシネーションによる事実の誤りを防ぐ、先駆的かつ唯一の AI セーフガードであり、99% の精度で検証可能な説明を提供します。これは、AWS のストレージ、アイデンティティ、ネットワーキング全体で 10 年以上にわたり形式的手法を適用してきた経験を基に磨き上げてきたものです。Amazon Bedrock はさらに、有害なコンテンツをブロックしコンテンツポリシーを適用するカスタマイズ可能なガードレールに加え、ワークロード全体にわたって AI の動作を追跡し異常を検出する包括的なオブザーバビリティも提供します。 脅威の状況は待ってくれない 脅威の状況は、こちらの対応を待ってはくれません。国家レベルの攻撃者、ランサムウェアオペレーター、サプライチェーン攻撃者は、すでに AI を活用して攻撃のスケールを拡大しています。AWS の使命は、まず防御を構築し、大規模にデプロイし、そこで得た知見をコミュニティ全体に共有・還元することで、常に一歩先を行くことです。 これこそ AWS が日々実践していることです。お客様にお使いいただく前に、まず自社の運用でテクノロジーが機能することを実証しています。標準に従うのではなく、自ら標準を打ち立てています。そして、先を見越して明日の課題に今日から取り組んでいます。 AI の機能がどれだけ進化しても、このアプローチは変わりません。AWS は引き続き防御を先に構築し、大規模な運用の中で改良を重ねていきます。そして Anthropic のようなパートナーと協力し、次世代の AI セキュリティツールがこの規模で防御を行うエンタープライズの実際のニーズに応えられるよう取り組んでいきます。 関連情報 AWS Security Agent の利用を開始する AI コンテンツの安全性を実現する Amazon Bedrock Guardrails を確認する Securing AI at AWS で取り組みを確認する AWS Responsible AI について確認する AWS AI Compliance について確認する 新たな脅威について AWS Security Bulletins を確認する Amy Herzog Amy Herzog は Amazon Web Services (AWS) のバイスプレジデント兼最高情報セキュリティ責任者 (CISO) です。セキュリティを最優先に掲げる AWS において、クラウドセキュリティプロフェッショナルのグローバル組織を率いています。AWS 入社前は、Amazon の Devices and Services、Media and Entertainment、Advertising の各事業で CISO を務め、Alexa+ や Ring などのコンシューマーテクノロジー製品のセキュリティを統括しました。また、低軌道衛星を通じて世界中のお客様やコミュニティに高速かつ高信頼のブロードバンドを提供する Amazon のイニシアチブである Project Kuiper のセキュアな開発にも重要な役割を果たしました。 <!-- '"` --> 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

目次 はじめに ECR イメージスキャンとは 構成の全体像 検知の網羅性 通知のノイズ低減 認知のスピード コスト 試算の考え方 試算例 Terraform による構築 1. ECR スキャン設定 2. EventBridge ルール 3. SNS トピック 4. AWS Chatbot（Slack 通知） 実際の通知と運用 導入してみて まとめ はじめに こんにちは、開発本部開発1部トモニテグループのエンジニアの パンダム/rymiyamoto です。 2025年末に Next.js の React Server Components に DoS（サービス拒否）とソースコード露出の脆弱性が公開 され、App Router を使用するサービスでのアップグレード対応が求められました。 このように、利用しているフレームワークやライブラリに深刻な脆弱性が見つかることは珍しくありません。 こうした脆弱性が公開中のサービスに影響していないかを素早く把握できる体制を整えるべく、弊社でも ECR のイメージスキャンを導入しました。 本記事では、その取り組みの一つとして ECR のイメージスキャンを導入した際の設計・構築・運用について紹介します。 同じように ECR のイメージスキャンをこれから導入しようとしている方の参考になれば幸いです。 ECR イメージスキャンとは Amazon ECR のイメージスキャンは、コンテナイメージに含まれるソフトウェアの脆弱性（CVE）を検出する機能です。 スキャンには Basic Scanning と Enhanced Scanning の2種類があります。 項目 Basic Scanning Enhanced Scanning スキャンエンジン Clair（オープンソース） Amazon Inspector2 検出対象 OS パッケージの脆弱性 OS パッケージ + プログラミング言語パッケージ（npm, pip, Maven 等） スキャンタイミング プッシュ時 / 手動 プッシュ時 / 継続スキャン 料金 無料 有料（スキャンしたイメージ数に応じた従量課金） 構成の全体像 導入した構成は以下の通りです。 ECR Enhanced Scanning (Inspector2) ↓ 脆弱性検知 EventBridge Rule (CRITICAL のみフィルタ) ↓ SNS Topic ↓ AWS Chatbot → Slack チャンネルに通知 設計にあたって意識したのは以下です。 検知の網羅性 OS パッケージだけでなく言語パッケージもカバーしたかったため、Enhanced Scanning を採用しました。対応言語の詳細は公式ドキュメントを参照してください。 docs.aws.amazon.com 一方で、OS パッケージの脆弱性検知だけで十分なケースや、まずは無料で始めたいケースでは Basic Scanning も有力な選択肢です。自社の要件に合わせて検討してみてください。 通知のノイズ低減 すべての severity を通知すると対応が追いつかなくなるため、まずは CRITICAL に絞って運用を開始しました。実際に HIGH まで含めて試してみたところ、本当に対応すべき通知が埋もれかねないと感じたので、まずは CRITICAL で運用を開始し、必要に応じてフィルタを広げる方針としています。 認知のスピード 脆弱性の存在に気づかないことが一番のリスクなので、Slack への即時通知を組み込みました。Slack への通知方法としては EventBridge → Lambda で通知内容をカスタマイズする方法もありますが、今回はまず検知できる状態を素早く作ることを優先し、コードを書かずに構築できる AWS Chatbot を採用しました。 コスト Enhanced Scanning は Amazon Inspector2 の料金体系に基づきます。料金は以下の2つで構成されます（2026年4月時点）。 最新の料金は公式ドキュメントをご確認ください。 aws.amazon.com 初回スキャン: イメージがプッシュされた時のスキャン、$0.09 / イメージ 再スキャン: 継続スキャンにより新しい CVE が公開された際の自動再スキャン、$0.01 / イメージ 試算の考え方 スキャン頻度によってコストの構造が異なります。 スキャン頻度 発生するコスト 計算式 プッシュ時 初回スキャンのみ 月間プッシュ数 × $0.09 継続スキャン 初回スキャン + 再スキャン 上記 + 保持イメージ数 × 再スキャン回数/月 × $0.01 弊社では本番環境は継続スキャン、開発環境はプッシュ時スキャンで運用しています。本番環境では新しい CVE が公開されたタイミングでも即座に検知したいため継続スキャン、開発環境では脆弱性を含む実装が入った時点で素早く検知しつつコストも抑えたいためプッシュ時スキャンが適しています。 試算例 例えば、5つのリポジトリに対して月間100回プッシュし、本番では各リポジトリに2イメージを保持（計10イメージ）するケースで試算します。再スキャン回数は月にどれくらいの頻度で対象の CVE が新たに公開されるかに依存しますが、ここでは月15回程度を見込みました。 項目 計算式 コスト 初回スキャン 100 push × $0.09 $9.00 再スキャン 10 images × 15回 × $0.01 $1.50 月額合計 $10.50 実際のコストはリポジトリ数・プッシュ頻度・保持イメージ数によって変わるので、自社の運用に合わせて試算してみてください。 Basic Scanning（無料）と比較するとコストはかかりますが、言語パッケージの脆弱性検知や新規 CVE の自動再スキャンが得られることを考えると、検討する価値はあると思います。 Terraform による構築 1. ECR スキャン設定 まず ECR レジストリに対して Enhanced Scanning を有効化します。 resource &quot;aws_ecr_registry_scanning_configuration&quot; &quot;this&quot; { scan_type = &quot;ENHANCED&quot; rule { scan_frequency = &quot;CONTINUOUS_SCAN&quot; repository_filter { filter = &quot;*&quot; filter_type = &quot;WILDCARD&quot; } } } filter = "*" でレジストリ内のすべてのリポジトリをスキャン対象にしています。リポジトリを個別に指定する方法もありますが、新しいリポジトリを追加した際にスキャン対象への追加を忘れるリスクがあるため、ワイルドカードで全体を対象にしています。 scan_frequency は環境によって使い分けています。本番環境では CONTINUOUS_SCAN 、開発環境では SCAN_ON_PUSH を設定しています。 2. EventBridge ルール resource &quot;aws_cloudwatch_event_rule&quot; &quot;ecr_scan_finding&quot; { name = &quot;ecr-scan-finding-notification&quot; event_pattern = jsonencode ( { &quot;source&quot; : [ &quot;aws.inspector2&quot; ] , &quot;detail-type&quot; : [ &quot;Inspector2 Finding&quot; ] , &quot;detail&quot; : { &quot;status&quot; : [ &quot;ACTIVE&quot; ] , &quot;severity&quot; : [ &quot;CRITICAL&quot; ] , &quot;resources&quot; : { &quot;type&quot; : [ &quot;AWS_ECR_CONTAINER_IMAGE&quot; ] } } } ) state = &quot;ENABLED&quot; } resource &quot;aws_cloudwatch_event_target&quot; &quot;ecr_scan_finding_sns&quot; { rule = aws_cloudwatch_event_rule.ecr_scan_finding.name arn = var.ecr_scan_finding_sns_topic_arn } Enhanced Scanning では Inspector2 がスキャンエンジンとなるため、イベントソースは aws.inspector2 になります。 Basic Scanning の場合は aws.ecr になるので注意が必要です。 3. SNS トピック EventBridge から受け取ったイベントを AWS Chatbot に渡すための SNS トピックを作成します。 resource &quot;aws_sns_topic&quot; &quot;ecr_scan_finding_topic&quot; { name = &quot;ecr-scan-finding-topic&quot; } resource &quot;aws_sns_topic_policy&quot; &quot;ecr_scan_finding_topic_policy&quot; { arn = aws_sns_topic.ecr_scan_finding_topic.arn policy = data.aws_iam_policy_document.sns_ecr_scan_finding_topic_policy.json } data &quot;aws_iam_policy_document&quot; &quot;sns_ecr_scan_finding_topic_policy&quot; { # EventBridge からの Publish を許可 statement { sid = &quot;AllowEventBridgeToPublishSNS&quot; effect = &quot;Allow&quot; actions = [ &quot;sns:Publish&quot; ] principals { type = &quot;Service&quot; identifiers = [ &quot;events.amazonaws.com&quot; ] } resources = [ aws_sns_topic.ecr_scan_finding_topic.arn ] condition { test = &quot;StringEquals&quot; variable = &quot;AWS:SourceAccount&quot; values = [ data.aws_caller_identity.current.account_id ] } condition { test = &quot;ArnEquals&quot; variable = &quot;aws:SourceArn&quot; values = [ &quot;arn:aws:events:$ { data.aws_region.current.name } :$ { data.aws_caller_identity.current.account_id } :rule/ecr-scan-finding-notification&quot; ] } } # Chatbot からの Subscribe を許可 statement { sid = &quot;AllowChatbotToSubscribe&quot; effect = &quot;Allow&quot; actions = [ &quot;sns:Subscribe&quot; ] principals { type = &quot;Service&quot; identifiers = [ &quot;chatbot.amazonaws.com&quot; ] } resources = [ aws_sns_topic.ecr_scan_finding_topic.arn ] condition { test = &quot;StringEquals&quot; variable = &quot;AWS:SourceAccount&quot; values = [ data.aws_caller_identity.current.account_id ] } condition { test = &quot;ArnEquals&quot; variable = &quot;aws:SourceArn&quot; values = [ &quot;arn:aws:chatbot::$ { data.aws_caller_identity.current.account_id } :chat-configuration/slack-channel/alert-to-slack&quot; ] } } } SNS トピックポリシーでは、EventBridge からの Publish と Chatbot からの Subscribe のみを許可しています。 condition で発信元を絞ることで、意図しないリソースからの操作を防いでいます。 4. AWS Chatbot（Slack 通知） 最後に、SNS トピックのメッセージを Slack に転送する Chatbot の設定です。 resource &quot;aws_chatbot_slack_channel_configuration&quot; &quot;chatbot_alert_to_slack&quot; { configuration_name = &quot;alert-to-slack&quot; slack_channel_id = &quot;XXXXXXXXX&quot; # 通知先の Slack チャンネル ID slack_team_id = &quot;XXXXXXXXX&quot; # Slack ワークスペース ID iam_role_arn = var.chatbot_role_arn sns_topic_arns = [ var.ecr_scan_finding_topic_arn, # 他の通知用 SNS トピックもここに追加できる ] guardrail_policy_arns = [ &quot;arn:aws:iam::aws:policy/ReadOnlyAccess&quot; ] logging_level = &quot;ERROR&quot; } これで CRITICAL な脆弱性が検知された際に、Slack チャンネルに通知が届くようになります。 なお、AWS Chatbot では同じ Slack チャンネルに対して複数の configuration を作成できません。そのため configuration_name は alert-to-slack のように汎用的な名前にしています。こうしておけば、今後 WAF のアラートなど別の通知を追加したくなっても sns_topic_arns にトピックを足すだけで済みます。 実際の通知と運用 実際に届く通知は以下のような形式です。 最初は CVE の詳細まで Slack で確認できるものだと思っていたのですが、実際に届く通知には Inspector2 Finding というイベント名と対象の ECR イメージの ARN が表示されるだけで、CVE 名もパッケージ名も表示されませんでした。 そのため、EventBridge の input_transformer を使い、Chatbot のカスタム通知で通知内容を改善しました。 resource &quot;aws_cloudwatch_event_target&quot; &quot;ecr_scan_finding_sns&quot; { rule = aws_cloudwatch_event_rule.ecr_scan_finding.name target_id = &quot;SendToSNS&quot; arn = var.ecr_scan_finding_sns_topic_arn input_transformer { input_paths = { &quot;severity&quot; = &quot;$.detail.severity&quot; &quot;title&quot; = &quot;$.detail.title&quot; &quot;description&quot; = &quot;$.detail.description&quot; &quot;repository&quot; = &quot;$.detail.resources[0].details.awsEcrContainerImage.repositoryName&quot; } input_template = &lt;&lt;TEMPLATE { &quot;version&quot;: &quot;1.0&quot;, &quot;source&quot;: &quot;custom&quot;, &quot;content&quot;: { &quot;textType&quot;: &quot;client-markdown&quot;, &quot;title&quot;: &quot;:rotating_light: ECR &lt;severity&gt; 脆弱性検出 [環境名 (AWSアカウントID)]&quot;, &quot;description&quot;: &quot;*重要度*: &lt;severity&gt;\n*リポジトリ*: &lt;repository&gt;\n*脆弱性*: &lt;title&gt;\n*詳細*: &lt;description&gt;&quot; } } TEMPLATE } } ポイントは input_paths でイベントから必要な項目を抽出し、カスタム通知フォーマットで整形している点です。改善後の通知は以下のような形式です。 CVE-ID やパッケージ名、リポジトリ名が表示されるようになり、Slack 上で脆弱性の概要を把握できるようになりました。詳細な対応判断が必要な場合は Inspector2 のダッシュボードを確認する運用ですが、通知を見ただけで対応要否がわかることが増えました。 さらに通知内容を自由にカスタマイズしたい場合は、EventBridge → SNS → Chatbot の経路ではなく、EventBridge → Lambda で整形する方法もあります。 導入してみて CRITICAL に絞った判断はうまくいきました。最初の通知が来たときも「これは本当に対応が必要なものだ」と落ち着いて対処できたので、狙い通りでした。 一方で、Chatbot のデフォルトの通知では CVE の詳細が出ず、正直もう少し情報が出ると思っていました。実際に使ってみて初めて気づいた部分で、 input_transformer を使ってカスタマイズできることも後から知りました。 Terraform での複数環境展開やスキャン頻度の使い分けはすんなりいきました。 まとめ 今回は、フレームワークやライブラリの脆弱性に素早く対応できる体制づくりの一環として、ECR の Enhanced Scanning を導入した事例を紹介しました。 構成としては ECR Enhanced Scanning → EventBridge → SNS → Chatbot → Slack というシンプルなパイプラインですが、Terraform でコード化することで再現性のある形で複数環境に展開できました。 まず検知できる状態を作ることが第一歩、そこさえ超えれば運用しながら精度を上げていけます。本記事がその一歩を踏み出すきっかけになれば嬉しいです。 最後まで読んでいただきありがとうございました！