[アップデート] AWS Continuum のペネトレーションテストが CI/CD パイプライン統合に対応したので GitHub Actions で試してみた

[アップデート] AWS Continuum のペネトレーションテストが CI/CD パイプライン統合に対応したので GitHub Actions で試してみた

CI/CD統合できるようになった。料金的に頻繁に呼び出せるものではないが...
2026.10.08

いわさです。

AWS Continuum for Penetration Testing(旧 AWS Security Agent)は、AWS アカウント内でペネトレーションテストを実行できるサービスです。
先日のアップデートで、このペネトレーションテストを CI/CD パイプラインに直接組み込めるようになりました。ペネトレーションテスト自体は GA なのですが、今回の CI/CD 統合はパブリックプレビューという位置づけです。

https://aws.amazon.com/about-aws/whats-new/2026/10/aws-continuum-penetration-testing/

今までは、ペネトレーションテストを実行するにはコンソールやオンデマンド実行で別途トリガーする必要があったのですが、今回のアップデートによってデプロイした変更に対してペネトレーションテストを走らせて、深刻な検出があった場合の自動リリースなどをブロックできるようになります。

今回こちらを使ってみたので紹介します。

使い方

対応している CI/CD プラットフォームは GitHub Actions / GitLab CI/CD / Bitbucket Pipelines / Azure DevOps Pipelines の 4 つです。
今回は GitHub Actions で試してみました。

使い方ですが、GitHub Actions のパイプラインで AWS 公式アクションの aws-actions/aws-continuum-run-pentest@v1 が使えるようになっているのでこちらを呼び出します。
GitHub と OIDC で IAM ロールの連携を行いますが、今回の機能を使う場合ロールには公式ドキュメントで次の 6 アクションを付与するように記載されています。

securityagent:StartPentestJob / BatchGetPentestJobs / StopPentestJob / ListFindings / BatchGetFindings / ListIntegratedResources

  security-pentest:
    needs: [deploy]
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: write
      actions: read
      deployments: read
      security-events: write
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.CONTINUUM_ROLE_ARN }}
          aws-region: ap-northeast-1
          role-duration-seconds: 7200
      - uses: aws-actions/aws-continuum-run-pentest@v1
        with:
          agent-space-id: ${{ vars.CONTINUUM_AGENT_SPACE_ID }}
          pentest-id: ${{ vars.CONTINUUM_PENTEST_ID }}
          severity-threshold: HIGH
          timeout-minutes: 60
          fail-on-error: true
          on-scope-conflict: block
          upload-sarif: true

パラメータとして Agent Space ID(as-...)とペネトレーションテスト ID(pt-...)、リージョンを渡していますね。
それぞれの ID の探し方がわからなかったのですが、Security Agent のペネトレーションテスト作成後の URL から見つけることが出来ました。

44A16B91-A84D-4BD5-A30C-2C60910E82FE.png

そしてその ID やロール ARN を GitHub の Secrets / Variables 経由で渡すようにしています。

ちなみにペネトレーションテスト自体は AWS アカウント内の Security Agent 側で走ります。そちらのテスト実行時間の料金はもちろん発生します。
CI/CD ランナー側でやるのはジョブの起動・完了待ち・結果の報告だけです。

dry-run で設定を検証する

今回は検証用に、CloudFront + S3 で配信する 1 ページだけの静的サイトを用意しました。

いきなり本番ゲートを走らせる前に、公式ドキュメントでも dry-run での検証が推奨されています。
インフラエラー時のデフォルトが fail-open(テストせず通過)なので、設定ミスがあると気づかないまま通ってしまうらしい。

dry-run は AWS の認証・リージョン・リポジトリ連携の解決だけを確認して、料金が発生するペネトレーションテストジョブは起動しません。
検証用に dry-run だけを行うワークフローを別に用意して、Actions タブから手動実行しました。

      - uses: aws-actions/aws-continuum-run-pentest@v1
        with:
          agent-space-id: ${{ vars.CONTINUUM_AGENT_SPACE_ID }}
          pentest-id: ${{ vars.CONTINUUM_PENTEST_ID }}
          dry-run: true

実行結果はこんな感じです。

E26D0543-7D41-46AB-A69E-8A791BBCCBB7.png

「脆弱性ゼロで通過」ではなく「設定チェックに合格」というところまでわかりますね。
dry-run はペネトレーションテストのジョブを起動しないので、コンソール(ウェブアプリ)側の実行一覧には何も残っていませんでした。

BA618988-A9D6-4DE9-8298-FA17ACC45B64.png

本番ゲートを実行してみる

dry-run が通ったので本番ゲートを実行したら、今度は別のエラーで止まりました。

03854FAA-1EE8-4122-85F6-5928993C3F77.png

ゲートジョブが StartPentestJob を呼ぶ手前で、API が HTTP 400 で止まってますね。

CI/CD pentesting is not enabled for this pentest.

公式ドキュメントの「Before you start」に記載されているのですが、手順をひとつすっ飛ばしてしまっていました。CI/CD モードを有効化する必要があります。

Enable CI/CD mode on the penetration test, and note the Agent Space ID (as-…) and penetration test ID (pt-…).

コンソールでいうこちらですね。

DC71B8A9-A470-472C-B03E-8B2C911B3CD9.png

こちらを有効化すると Continuous pentesting のタブが表示されるようになりました。

FF7D6EFD-E862-4063-B9D0-78DEE18FC6E5.png

有効化まで済んだので、本番ゲートのワークフローを手動実行しました。
ここからは実際のペネトレーションテストジョブが起動するので、料金が発生しますのでご注意ください。

4CD0538A-C6E8-448A-BD3B-C9A7A78E4C36.png

Security Agent 側を見てみると、ジョブが自動実行されていることがわかりますね。良いですね。

C0D191BB-601A-4F18-94CD-DBA4A7331FB6.png

88F56438-210B-43AA-B9A6-DAFDBF155DE6.png

ちなみに料金発生させたくなかったので、私は途中でジョブを中断させました。

さいごに

本日は AWS Continuum for Penetration Testing の CI/CD パイプライン統合(パブリックプレビュー)を GitHub Actions で試してみました。
デプロイのワークフローの中にセキュリティ検証を組み込めるのは良いですね。

このほか、公式ドキュメントには GitLab や Bitbucket 固有の注意(GitLab はパイプライン変数でゲート設定を上書きできる、Bitbucket はパイプラインをキャンセルしてもジョブが止まらないことがある)もまとまっていました。
今回は GitHub Actions だけ試したので、他プロバイダを使う場合はそのあたりも確認しておくとよさそうです。

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事