AWS セキュリティハンズオン連続開催のご案内
https://aws.amazon.com/jp/blogs/news/aws-security-handson-series/
本記事では、上記のハンズオンの11/6開催回に参加した際の内容をもとに、オプションとして紹介されていた GitHub 連携について詳しく補完します。ハンズオンの手順だけでは分かりにくい GitHub 側の操作も、実際の画面を交えながら紹介します。
同じ内容のハンズオンは11/27にも開催される予定で、12月以降も定期的に開催されると思われます。また、後日ハンズオンの手順書が公開される可能性もありますので、そちらと合わせてご参照ください。
AWS Security Agent を試すには、AWS 側のエージェントスペース、GitHub App、レビュー対象のアプリケーションなど、いくつかの準備が必要です。本記事では、実際に操作した画面を掲載しながら、準備からレビュー結果の確認までを、少し気楽に追えるようにまとめます。
はじめに：10万行のコードと、ちょっとした不安
AIを使った開発では、短期間に大規模なコードを生成できます。最近は、有名 IT 企業の社長が「2か月で10万行のコードを書いた」といった話も話題になりました。まるで、開発チームに強力な援軍が一気に現れたようで、聞いているだけでもワクワクします。
一方で、ここで少しだけ立ち止まりたいところです。そのコードのセキュリティは大丈夫でしょうか？
一見、画面操作や基本的な購入フローが動いていても、認証・認可、入力値検証、機密情報の扱いといった、通常の画面操作では見つかりにくいセキュリティ上の問題を見落とす可能性があります。コード量が増えるほど、人手だけで全体を確認することも難しくなります。
本記事では、バイブコーディングで生成した10万行のコードの代わりに、意図的に脆弱性を含む OWASP Juice Shop を使います。いわば、安心して訓練できる演習場です。
これを GitHub の private リポジトリに用意し、AWS Security Agent のコードレビューを実行した記録をまとめます。GitHub App の接続、レビューの実行、サンドボックスでの検証、検出結果の確認、自動生成された修正 PR のレビュー、修正後の再検証までを、画面キャプチャとコマンドを交えて説明します。長めの記事ですが、気になる章からつまみ食いしても大丈夫です。
ここで扱うのは検証用アプリケーションです。実際のサービスをレビューする場合は、対象リポジトリの権限、実行ロール、ログに含まれる情報、テストにかかる時間と料金を事前に確認してください。
AWS Security Agent はコードレビュー以外にも、ペネトレーションテスト、仕様に対するデザインレビュー、STRIDE に基づく脅威分析などに利用できます。今回はその中から、コードレビューから修正・再検証までの流れに焦点を当てます。まずは偵察、次に分析、最後に実際の動作確認――少しだけ『攻殻機動隊』のような気分で、アプリケーションの内側と外側を眺めていきましょう。
AWS Security Agent とは
AWS Security Agent（AWS セキュリティエージェント）については、公式ページで詳しく紹介されています。
AWS Security Agent（AWS セキュリティエージェント）は、開発ライフサイクル全体でアプリケーションを積極的に保護する「フロンティアエージェント」です。
主な機能（ユースケース）は次のとおりです。
- オンデマンドのペネトレーションテスト: アプリケーションに合わせた複数ステップの攻撃シナリオで、OWASP Top 10やビジネスロジックの欠陥を含む脆弱性を検証します。再現可能な攻撃経路、影響分析、すぐ使える修正案がレポートされます。
- 設計セキュリティレビュー: 製品仕様書やアーキテクチャ文書を、AWSのベストプラクティスや組織のセキュリティ要件に照らして分析します。
- コードセキュリティレビュー: プルリクエストを自動で分析し、開発者のワークフロー内で修正ガイダンスを提供します。
特徴は、次のとおりです。
- アプリケーションのコンテキストを把握し、自動スキャンツールでは見逃す脆弱性を実際に悪用できるかまで検証します。
- テストを数週間から数時間に短縮でき、APIでCI/CDパイプラインにも組み込めます。
- セキュリティチームが組織の基準を一度定義すれば、設計・コードのレビューごとに自動で検証されます。
導入事例として、SmugMug、HENNGE、Wayspring、クラスメソッド、Bamboo Healthが掲載されています。
AWS Security Agent のコードレビュー：まずは作戦を確認する
AWS のドキュメントでは、コードセキュリティレビューについて次のように説明されています。
AWS Security Agent には、リポジトリ全体を対象にしたコードレビューと、接続したリポジトリのプルリクエストを対象にした分析があります。コードレビューでは、GitHub、GitLab、Bitbucket、GitHub Enterprise Server のリポジトリや S3 バケットのソースコードをスキャンし、セキュリティ脆弱性の検出や、コードベース全体の組織要件への準拠を確認できます。
AWS Security Agent はコードの変更を確認し、プルリクエストまたはマージリクエストのコメントとしてセキュリティ検出結果を直接投稿します。開発者は修復ガイダンスを受け取ることができ、特定された脆弱性のコード修正を含むプルリクエストを自動生成することもできます。
今回は、GitHub 統合機能を有効にして、OWASP Juice Shop をベースにした GitHub リポジトリへコードレビューを実行します。最初から本番リポジトリへ飛び込まず、検証用リポジトリで手順と権限を確認するのがポイントです。
構成の全体像：舞台裏を先に見る
今回の環境では、CloudFormation で AWS Security Agent のエージェントスペースや、レビュー対象アプリケーションを構築しました。画面から見るとシンプルなコードレビューですが、舞台裏では複数の AWS リソースが連携しています。
AWS Security Agent に関連するリソースを抜き出すと、エージェントスペース、GitHub 連携、S3 バケット、CloudWatch Logs、サービスロールなどで構成されています。
レビュー対象の OWASP Juice Shop を準備する：まずは普通に動かす
前提条件
今回の検証では、AWS Security Agent を利用できる AWS アカウント、GitHub アカウント、GitHub Codespaces、CloudFormation で構築した検証用 AWS 環境を使用しました。いきなり難しい設定に進む前に、まず「アプリが起動し、ログインや購入操作ができる」状態を作っておくと、後の検証結果を判断しやすくなります。AWS Security Agent の提供リージョン、プレビュー機能の提供状況、必要な IAM 権限は変更される可能性があるため、実行時点の AWS ドキュメントも確認してください。
GitHub にリポジトリを用意する
AWS Security Agent から参照できるように、レビュー対象の Juice Shop を自分の GitHub アカウントへ private リポジトリとして取り込みました。
GitHub の Import repository 画面で、元のリポジトリ URL、所有者、リポジトリ名を指定します。今回は公開せず、private リポジトリとして作成しました。
インポートが完了すると、作成したリポジトリを利用できるようになります。
GitHub Codespaces を起動する
レビュー対象には、意図的に脆弱性を含む OWASP Juice Shop を使用します。まず、GitHub 上でリポジトリを用意し、Codespaces から開発環境を起動しました。ここは「敵がいるか」ではなく、「そもそも舞台の幕が上がるか」を確認する時間です。
README の手順では、Node.js のインストール、リポジトリの clone、依存パッケージのインストール、アプリケーションの起動を行います。
依存パッケージをインストールすると、脆弱性の件数が npm の警告として表示されました。これはアプリケーション自体の脆弱性とは別に、依存パッケージについても確認が必要であることを示しています。
アプリケーションを起動すると、Codespaces のポートフォワーディング経由でブラウザから Juice Shop にアクセスできます。
Juice Shop を操作する
レビュー対象が実際に動作するアプリケーションであることを確認するため、ユーザー登録、ショッピングカート、注文までの操作を行いました。セキュリティレビューの前に正常系を一度通しておくと、後で「脆弱性の修正で機能まで壊れていないか」を比較できます。
注文完了後は、注文確認書を PDF として出力することもできます。
Juice Shop には、住所や決済情報などの入力画面も用意されています。これらの機能を含むため、認証、認可、入力値検証、機密情報の扱いなど、複数の観点からコードを確認できます。
AWS Security Agent と GitHub を統合する：連携の入口を作る
統合を追加する
AWS Security Agent のエージェントスペースで「統合」を開き、GitHub を選択します。ここからは画面の案内に沿って進めればよいのですが、権限だけは流し読みせず確認しておきましょう。
GitHub.com または GitHub Enterprise Server を選択できます。今回は GitHub.com を使用します。GitHub App の権限は、コードレビューコメントやコード修正を利用するため、読み取りと書き込みが可能な設定を選択しました。
ステップ3 AWS Security Agent を認証 の 認証する ボタンを押します。
GitHub App をインストールする
ここからの作業は GitHub にログインして行います。
AWS Security Agent GitHub App を開く
AWS Security Agent と GitHub を連携するため、AWS Security Agent の GitHub App をインストールします。
GitHub App のインストール先として自分のアカウントを選択し、対象リポジトリを限定します。今回は、先ほど作成した juice-shop-private のみを選択しました。
レビュー対象を限定しておくことで、意図しないリポジトリに AWS Security Agent がアクセスすることを避けられます。最初は対象を1つに絞ると、アクセス範囲の確認も簡単です。
インストール時には GitHub の追加認証が求められる場合があります。
AWS Security Agent の認証画面では、GitHub アカウントの識別、アクセス可能なリソースの確認、ユーザーに代わった操作について説明されます。内容を確認して認証を許可します。
インストール後は、GitHub の Settings > Applications からインストール済みの AWS Security Agent を確認できます。
以上で、GitHub 上の作業は完了です。ここまで来れば、連携の前半戦はクリアです。
AWS Security Agent での作業
GitHub での AWS Security Agent との連携が完了したら、AWS Security Agent の画面に戻って作業します。
AWS Security Agent が認証された状態に変わりました。
登録名と GitHub アカウントタイプを入力します。登録名は、後から画面上で識別しやすい名前にしておくと管理しやすくなります。
統合が正常に接続されると、エージェントスペースの画面に GitHub 接続済みのメッセージが表示されます。
利用可能な登録を選択する
コードレビューの設定画面から GitHub 統合を追加します。先ほど作成した登録を選択して次へ進みます。
リポジトリを接続する
レビュー対象の juice-shop-private を選択します。リポジトリタイプは private と表示されています。
接続対象を確認し、トリガーフィルターとコード修正を有効にします。トリガーフィルターを設定すると、指定した条件に一致するプルリクエストをコードレビューの対象にできます。
マネジメントコンソールの AWS Security Agent 側でコードレビューを設定する
AWS マネジメントコンソールの AWS Security Agent のコードレビュー設定では、GitHub リポジトリのほか、レビューで参照する S3 バケットを設定できます。ここは少し設定項目が多いので、ひとつずつ確認していきます。
レビュー内容は、次の 3 つから選択できます。
- セキュリティ要件の検証
- セキュリティ脆弱性検出結果
- セキュリティ要件と脆弱性検出結果
今回は、組織のカスタムセキュリティ要件と一般的なセキュリティ脆弱性の両方を確認できる「セキュリティ要件と脆弱性検出結果」を選択しました。迷ったら、最初はこの両方を確認できる設定が分かりやすいと思います。
CloudWatch Logs では、セキュリティテスト中のアプリケーションの動作を記録できます。コードレビュー環境のロググループを選択し、AWS リソースへのアクセスには既存のサービスロールを指定しました。
既存のロールを利用する場合、設定変更に伴ってポリシー更新が必要になることがあります。今回は、ポリシーを自動的に更新する確認画面が表示されました。
保存が完了すると、GitHub リポジトリ、S3 バケット、サービスロールがコードレビュー設定に反映されます。
AWS マネジメントコンソールの AWS Security Agent 側の設定作業は以上です。ここまで終わると、いよいよレビューを走らせられます。
AWS Security Agent アプリ側でコードレビューを作成する：いよいよ実行準備
AWS Security Agent のウェブアプリケーションを開き、コードレビューを作成します。
AWS マネジメントコンソールの AWS Security Agent で ウェブアプリケーションへのアクセス、管理者アクセス を押して、AWS Security Agent アプリを開きます。
コードレビュー を押して開きます。
コードレビューを作成する を押して、コードレビューを作成します。
レビュー名を入力し、ソースとして GitHub リポジトリを選択します。
コードレビュー用の IAM ロールと CloudWatch ロググループを指定します。自動コード修正を有効にすると、検出結果に対する修正を AWS Security Agent に生成させ、GitHub のプルリクエストとして送信できます。
コードレビューを実行する：ボタンを押す前に少しだけ確認
コードレビューを作成すると、レビュー一覧に表示されます。作成直後は、まだ実行結果がありません。ここで対象リポジトリとロールをもう一度確認してから、実行を開始します。
「レビューを開始する」を押して実行を開始します。実行中は、プリフライト、静的分析、検証、ファイナライズという段階で処理が進みます。いわば、偵察して、読み解いて、実際に試して、結果を整える流れです。
実行詳細画面では、現在のステップ、実行 ID、経過時間、コードレビューの概要を確認できます。
コードレビューのログには、ログ基盤のセットアップ、テスト環境の準備、アーキテクチャ分析、コードスキャナーによる分析など、AWS Security Agent が実行したタスクが表示されます。
レビューが進むと、検出結果の重大度別の件数と、リスクタイプ別の集計が表示されます。今回の実行では、重大、高、中、低の検出結果がそれぞれ確認できました。件数が多く見えても、まずは重大度と信頼度を分けて眺めると、優先順位を付けやすくなります。
検証ログでは、コードスキャナーが見つけた検出結果を、実際のアプリケーションの動作や再現手順と照合している様子を確認できます。
検出結果を確認する
検出結果の一覧では、各問題のタイトル、信頼度、重大度、検証状態を確認できます。たとえば、フロントエンドの公開バンドルに管理者アカウント用のデフォルト認証情報が埋め込まれているという、Critical の検出結果が表示されました。
検出結果の詳細画面では、問題の説明、リスクタイプ、重大度、検証状態、関連するセキュリティ要件を確認できます。
サンドボックスによる検証
検証フェーズでは、サンドボックス上でアプリケーションを起動し、ペネトレーションテストを行って検出結果を検証します。ソースコードを読むだけでは判断しにくい脆弱性についても、実際のアプリケーションに対するリクエストやレスポンスを確認しながら、再現性や影響を調べます。
この処理はコードレビューの実行と並行して進むため、開始直後は検証結果がまだ表示されない場合があります。検証ログでは、対象の検出結果、実行したタスク、エージェントからの応答を確認できます。
検証が完了した検出結果には、検証済みであることが表示されます。検出結果を修正する際は、静的解析の指摘だけで判断せず、検証ログに記録された再現手順やアプリケーションの挙動も確認します。
今回は、検証フェーズが予想以上に長時間実行されていました。ログを確認すると、どうやら権限まわりのエラーのようです。処理をそのまま待ち続けず、いったん停止して原因を確認しました。
今回は、環境設定の不備によりサンドボックステストがエラーを繰り返し、長時間実行されました。検証が進まない場合は、まずログでエラーの発生回数と原因を確認し、必要ならジョブを停止してから設定を修正します。
セキュリティチェックは実行時間とコストが増えやすいため、実運用では CloudWatch Logs のメトリクスフィルターやアラームで同じエラーの反復を検知し、停止判断につなげられるようにしておくと安全です。アラームだけで自動停止する場合は、誤検知による中断を避ける条件も検討してください。
コードレビューのジョブを管理する
コードレビューには時間がかかるため、実行中にブラウザを閉じても問題がないよう、コードレビューのトップページからジョブの状態を確認できます。作成したレビューごとに、実行開始時刻、ステータス、実行時間、検出結果の概要を確認できます。
今回のような検出結果では、単に「危険なコードがある」と通知されるだけではなく、どのファイルのどの処理が問題なのか、どのような攻撃につながる可能性があるのかを確認できます。修正を行う際は、検出結果、検証ログ、対象コードを突き合わせ、影響範囲と既存機能への影響を確認してから対応しましょう。
コードレビューの結果のレポート
GitHub で修正 PR を確認する：自動修正は「たたき台」
自動コード修正を有効にしている場合、AWS Security Agent は検出した脆弱性への修正を含む PR を GitHub に作成します。便利な機能ですが、ここで焦って「全部マージ」はしません。PR をそのまま取り込むのではなく、まず次の点を確認します。
- 修正対象の検出結果と PR の変更内容が対応しているか
- 変更によって既存の機能や API の挙動が変わっていないか
- 認証・認可、入力値検証、エラーハンドリングなどの周辺処理に不足がないか
- テストや依存パッケージの変更が適切か
内容に問題がなければレビューを承認し、ブランチへ取り込みます。自動生成された修正であっても、アプリケーションの要件や運用方針に適合するかを人が確認することが重要です。AI は頼れる副操縦士ですが、進路を決める船長は人間、というくらいの距離感がちょうどよいでしょう。
今回の PR についての所感
GitHub のリポジトリには、多数の修正 PR が作成されました。
いくつかの PR を確認すると、検出結果の説明や修正方針は参考になりますが、すべてをそのまま承認できる品質ではありませんでした。次は、認証情報のハードコードに関する PR を確認した例です。ここは「自動修正の強さ」と「人による確認の必要性」を同時に見られる場面です。
この PR については、以下のようにマージを見送りました。
他の 2 件の PR についても、同様にマージを見送りました。
自動生成 PR は、調査の出発点や修正案のたたき台としては有用です。ただし、次の観点を人が確認してから取り込む必要があります。
- 検出結果が実際の脅威モデルと一致しているか
- 修正が脆弱性を解消し、別の脆弱性や機能不全を生んでいないか
- 認証・認可、入力値検証、ログ出力、エラー処理、テストへの影響がないか
- 依存パッケージの更新で互換性やライセンス上の問題が生じないか
自分たちが管理するリポジトリであれば、ブランチ保護、必須レビュー、CI、デプロイ前の検証を前提に自動 PR を利用できます。一方、他者のリポジトリへ許可なく、または十分な説明なしに大量の PR を送る運用は避けるべきです。受け手のレビュー負荷が増え、内容を確認する前に通知が埋もれるためです。PR の本文に、対象となった検出結果、実行環境、未検証の範囲を明記し、必要な場合は事前に連絡する方が適切です。
AWS Security Agent が作成した PR の後続作業は、別のコーディングエージェントに引き継ぐこともできます。ただし、AI 同士で修正を連鎖させるのではなく、CI と人によるレビューを各段階の停止条件として設けます。銀河を艦隊で進むように、各工程に「ここで人が確認する」というチェックポイントを置いておくイメージです。AWS Security Agent の修正案を使わない場合でも、検出結果を入力として GitHub Copilot などに修正を依頼できますが、同じレビュー手順と検証基準を適用してください。
開発プロセスについて：後戻りを減らすには
今回のように大量の指摘が出ると、生成後に一括して修正するより、要件・脅威モデル・受け入れ条件を先に定義し、設計と実装の各段階で検証する方が効率的だと実感します。仕様駆動開発や脅威モデリングを導入しても脆弱性がゼロになるわけではありませんが、レビュー対象と判断基準が明確になり、後工程の修正量を抑えられます。最終話で全部解決するより、各話で少しずつ伏線を回収する方が、開発もレビューも楽になります。
私が以前 AI-DLC を実践した、スクリーンショット付きのガイドもあります。
銀河の歴史が、また1ページ。——「AI-DLC」という新戦術で、ゼロから始める新開発生活
記事は AI-DLC workflows v1 をベースにしています。v2 では機能が拡張されていますが、要件を整理し、人間が確認しながら AI と段階的に開発するという基本的な考え方は共通しています。興味があれば、こちらも休日のコーヒーのお供にどうぞ。
Codespaces で修正後の動作を確認する：修正が効いたか確かめる
PR を取り込んだ後、Codespaces で変更内容を取得します。
git checkout main
git pull origin main
npm install
npm start
実際の画面操作を行い、修正対象の脆弱性が再現しなくなったことを確認します。同時に、ログイン、商品購入、注文確定など、修正の影響を受ける可能性がある主要機能も確認します。セキュリティだけ直って、買い物ができなくなっていたら本末転倒なので、正常系も忘れずに確認します。
この段階では、AWS Security Agent の検出結果だけでなく、アプリケーションとして正常に動作することも確認します。検証結果や確認した操作は、PR のコメントや作業記録に残しておくと、後から修正の妥当性を追跡しやすくなります。
修正後の Docker イメージを作成する：検証結果をデプロイへつなぐ
今回は ECS のタスク定義で Docker イメージを指定して Juice Shop を実行しています。CloudFormation では、次の Image が実行するコンテナイメージに該当します。
# ECS Task Definition
TaskDefinition:
Type: AWS::ECS::TaskDefinition
Properties:
Family: juiceshop-task
NetworkMode: awsvpc
RequiresCompatibilities:
- FARGATE
Cpu: 2048
Memory: 4096
ExecutionRoleArn: !GetAtt TaskExecutionRole.Arn
ContainerDefinitions:
- Name: juiceshop
Image: public.ecr.aws/b1v6d1o7/workshop/juiceshop:experimental
PortMappings:
- ContainerPort: 3000
Protocol: tcp
LogConfiguration:
LogDriver: awslogs
Options:
awslogs-group: !Ref LogGroup
awslogs-region: !Ref AWS::Region
awslogs-stream-prefix: ecs
上記のイメージは Amazon ECR Public Gallery が公開しているコンテナイメージです。
Amazon ECR Public Gallery のイメージ
上記の公開イメージは自分のリポジトリではないため、修正後のコードから自分の ECR private リポジトリへイメージを作成して push し、CloudFormation の Image を自分のイメージ URI に変更します。以下は、リポジトリのルートで実行する例です。<account-id>、<region>、<tag> は自分の環境に置き換えてください。ここは実環境に影響する工程なので、検証用アカウントやタグを使い分けて、落ち着いて進めます。
aws ecr create-repository \
--repository-name juiceshop \
--region <region>
docker build -t <account-id>.dkr.ecr.<region>.amazonaws.com/juiceshop:<tag> .
aws ecr get-login-password --region <region> | \
docker login --username AWS --password-stdin \
<account-id>.dkr.ecr.<region>.amazonaws.com
docker push <account-id>.dkr.ecr.<region>.amazonaws.com/juiceshop:<tag>
この操作には、ECR リポジトリの作成・プッシュ権限と、ECS タスク実行ロールのイメージ取得権限が必要です。CloudFormation では、例えば次のように自分の ECR イメージを指定します。
Image: !Sub "${AWS::AccountId}.dkr.ecr.${AWS::Region}.amazonaws.com/juiceshop:<tag>"
ECS のタスク定義を更新してデプロイすると、修正後のコードを含むコンテナでアプリケーションを実行できます。これにより、AWS Security Agent のペネトレーションテストなど、他の機能でも修正後のアプリケーションを再テストできます。
なお、ECR のリポジトリ、イメージタグ、ECS タスク実行ロールの権限、CloudFormation の更新対象は、実際の環境に合わせて設定してください。latest のような可変タグではなく、コミット ID やビルド番号など変更不能なタグを使うと、どのコードをデプロイしたかを追跡しやすくなります。ECS がタグを再利用したイメージを確実に取得できるよう、デプロイ時にタスク定義のリビジョンも更新してください。
検証結果を整理する：次に同じことを再現できる形へ
今回の検証では、次の順番で修正の有効性を確認します。手順をメモとして残しておくと、次回のレビューや別の担当者への引き継ぎがぐっと楽になります。
- AWS Security Agent の検出結果と検証ログを確認する
- 自動生成された PR の差分、テスト、依存パッケージの変更をレビューする
- GitHub で PR を承認・マージする。必要なレビューと CI を完了させる
- Codespaces で修正後のコードを実行し、脆弱性の再現手順と主要機能を確認する
- 修正後のコードから Docker イメージを作成し、コミット ID などの固定タグで ECR に push する
- CloudFormation でタスク定義を更新し、ECS にデプロイする
- デプロイ後のアプリケーションを確認し、必要なら AWS Security Agent のコードレビューやペネトレーションテストを再実行する
まとめ：AIを味方にしつつ、最後は人が判断する
今回は、OWASP Juice Shop を GitHub の private リポジトリへ用意し、次の手順で AWS Security Agent のコードレビューを実行しました。
- GitHub にレビュー対象の private リポジトリを用意する
- GitHub Codespaces でレビュー対象のアプリを起動し動作確認を行う
- AWS Security Agent と GitHub を統合する
- AWS Security Agent GitHub App を対象リポジトリにインストールする
- コードレビュー対象のリポジトリを設定する
- コードレビューを作成して実行する
- コードレビューの検出結果と検証ログを確認する
- 自動生成された PR の変更内容をレビューする
- GitHub で PR を確認する。十分に吟味したのちに問題ない修正は取り込む
- Codespaces で修正後のコードを実行し、主要機能を確認する
- 修正後のコードから Docker イメージを作成して ECR に push する
- ECS を更新し、(開発環境に)デプロイ後のアプリケーションを確認する
- 問題が残っていれば、検出結果の確認に戻り、修正と再検証を繰り返す
- コードレビューおよびコードの修正が完了したら、AWS Security Agent の他の機能、ペネトレーションテストなどを実施する
AWS Security Agent のコードレビューでは、静的なコード分析だけでなく、検出結果の検証や、アプリケーションの動作を踏まえた分析も行われます。GitHub 連携と自動コード修正を組み合わせることで、検出結果の確認から修正プルリクエストの作成までを開発フローに組み込めます。コードの量が増えても、レビューの入口と出口を用意しておけば、少しずつ安全性を高めていけます。
一方で、GitHub App にはリポジトリへのアクセス権限が必要になるため、実運用では対象リポジトリを必要最小限に限定し、サービスロールや CloudWatch Logs の権限も確認したうえで導入することが重要です。
自動生成 PR はそのまま取り込めるとは限りませんが、検出結果の調査と修正のたたき台を作る機能として有用でした。特に、検出結果から PR 作成までを自動化できる点は、修正作業の開始を早めます。ただし、最終的な判断は検出結果、差分、テスト、実行環境のログを確認した人が行うべきです。自動化は「判断をなくす」ためではなく、「判断する材料を早くそろえる」ために使う、と考えると扱いやすくなります。
また、エージェントの自動実行中に、今回のようなサンドボックスの設定不備などでエラーが繰り返されると、処理時間とコストが増加します。導入時は小さな検証対象で動作を確認し、CloudWatch Logs の監視、ジョブの停止手順、IAM 権限の確認を整えてから対象範囲を広げることを勧めます。最初は小さく試し、ログを見て、直して、もう一度試す。このくらいのペースが、実運用ではちょうどよいと思います。
最後まで読んでいただき、ありがとうございました。