AWSは2026年10月14日付の公式記事で、アプリの変更を環境へ反映する「デプロイ」のたびに侵入テストを行う構成を紹介しました。稼働中のアプリで脆弱性を悪用できるか検証し、設定した重大度以上の問題が見つかれば、本番環境への移行を止められます。情シスと開発部門が確認したいのは、検査の導入方法だけでなく、未検査や検査エラーを本番移行の判定でどう扱うかです。
ステージングで変更分を検査し、本番移行を判定
使用するサービスは、旧称AWS Security Agentの「AWS Continuum for penetration testing」です。AWSによると、AIエージェントが稼働中アプリの悪用可能な脆弱性を検証します。
紹介された構成では、本番前の確認用環境であるステージングへデプロイした後に検査します。合格した場合だけ、本番へ移行します。検査対象は、前回合格したコミットから今回までの変更です。コミットは、リポジトリに記録されたコードの変更単位を指します。AWSは、変更に絞ることで毎回の検査に適した速度と費用になるとしています。
検査はAWSアカウント内で動きます。ビルドやデプロイを自動実行するCI/CDの実行環境では動きません。GitHub Actionsなど4種のCI/CDに適用でき、記事ではGitHub Actions向けの具体的なワークフロー例を示しています。
日本での提供は発表には書かれていません。日本語対応、日本の価格、対応リージョンの一覧は示されていません。ワークフロー例ではus-west-2が指定されています。
「合格」が示す範囲と、止まらない条件を確認
攻撃の対象となる部分を変えた変更は、検出結果を重大度のしきい値で判定します。一方、対象範囲内でもセキュリティに関わる変更がなければ合格となります。設定範囲外で未検査の変更を、本番移行の阻止対象にするかどうかも選べます。したがって、合格という結果だけで、すべての変更を検査済みと扱わないことが重要です。
重大度、範囲外の変更、基盤エラーの扱いは、それぞれ独立した設定です。基盤エラーで処理を失敗させる設定は初期値がfalseで、本番移行を阻止しません。AWSは、セキュリティ承認が必要な構成では、この設定をtrueにするよう推奨しています。
また、AWSはしきい値NONEの報告のみの運用から、HIGHへ段階的に移す方法を紹介しています。ただし、報告のみでも合格すると、次回検査の基準コミットが更新されます。後から判定を厳しくしても、以前の報告対象は自動で再検査されません。過去の範囲を再評価するには、開始・終了コミットの識別子であるSHAを指定する方法があります。
影響する会社・しない会社
- 影響する: GitHub Actionsなどでアプリのデプロイを自動化し、本番移行前に侵入テストを組み込みたい会社です。導入には、IAMというAWSの権限管理を設定できるAWSアカウントと、検査可能なステージング環境が必要です。
- 影響する: 報告のみの運用から、本番移行を止める運用へ切り替える会社です。過去の報告対象を改めて評価するか、基盤エラーでも本番移行を止めるかを決める必要があります。
- 影響しない: この構成を導入しない会社に対する設定変更や更新の義務は、発表には書かれていません。AWS利用企業すべてへの強制適用として紹介されたものではありません。
情シスが今日やること
- 開発責任者と導入条件を確認します。 CI/CDのワークフロー設定で、ステージングへのデプロイと本番移行の位置を確認します。あわせて、IAM設定権限を持つ担当者と、検査対象のステージング環境を特定します。まずは本番移行前のどこに検査を入れるかを整理します。
- 初期設定と認証方式を確認します。 導入する場合は、対象ドメインを検証し、CI/CDモードを有効にしてリポジトリを接続します。認証はOIDCという認証連携方式と一時認証情報を使い、長期アクセスキーの保存は不要とされています。導入前には、検査ジョブを開始しないdry-runで設定を確認します。
- 移行を止める条件を、運用開始前に合意します。 ワークフロー設定で、重大度、範囲外の変更、基盤エラーの3項目を別々に確認します。セキュリティ担当者と本番移行の承認者へ、基盤エラー時の初期値はfalseであることを伝えます。承認が必要な構成では、AWSの推奨に沿ってtrueへの変更を検討します。
- 判定を厳しくする前に、過去の範囲を整理します。 NONEからHIGHへ移す場合は、以前の報告対象と基準コミットを開発担当者に確認してもらいます。再評価が必要なら開始・終了コミットのSHAを指定します。GitLab CI/CDを使う場合は、検査条件が変数の上書きで緩められないよう、変数を変更できる権限も確認します。
