🏗️

「AWS CODEBUILD SECURITY NOTIFICATION」どうすれば良い？

に公開
AWS
GitHub
CI/CD
Webhook
CodeBuild
tech

はじめに

皆様、こんにちは！😊 最近、AIの進化に頑張ってしがみつきつつ、AWS運用もしている @___nix___ です。こんな時こそ、皆さんの役に立つ情報を届けられるようこの記事を書いています。

背景

AWS CodeBuild と GitHub などのソースリポジトリ連携は非常に便利ですよね。プッシュやプルリクエストのイベントで自動ビルドをトリガーできるなんて、CI/CD 運用にはまさに必須といっても過言ではありません。

しかし、この機能には潜在的なリスクも潜んでいました。
皆様のところにも以下のような通知が届いたでしょうか。

AWS CODEBUILD SECURITY NOTIFICATION

AWS CodeBuild において、対応が必要となる可能性のある問題を確認いたしました。この問題により、アクターはプルリクエスト (PR) のビルドプロセス中にソースコードリポジトリ (GitHub、BitBucket、GitLab など) のアクセストークンを抽出できる可能性があります。具体的には、お客様のリポジトリの1つに PR を送信する権限を持つ者がおり、その PR コードが CodeBuild のビルドステップの一部として自動的に実行される場合、影響を受ける可能性があります。この問題は CodeBuild のすべてのリージョンで発生しています。信頼できないリポジトリコントリビューターによる自動 PR ビルドの使用は避けることを強く推奨いたします。

特に、未信用のプルリクエスト投稿者によって、ビルド環境内のアクセストークンが不正に取得されるという話です。これは、自動 PR ビルドの設定によっては起こり得る、見過ごせないセキュリティリスクです。

概要

では、どうやって調べたのか、実践的な方法をご紹介しますね。理論よりも実際に使える情報が大事！というのが私のポリシーです。

今回の調査の目的は、Webhook イベント設定の中に「PULL_REQUEST_CREATED」などのプルリクエストイベントが含まれているかを確認し、自動 PR ビルドによるトークン漏洩リスクの有無を把握することでした。効率性を重視し、簡潔に必要な情報をまとめます。

調査

実際の調査では、以下のようなShellScriptを作成して確認を行いました。

このスクリプトは、指定されたリージョン内のCodeBuildプロジェクトを一つ一つ確認し、Webhook設定の有無、そして何よりもプルリクエストに関連するイベント（PULL_REQUEST_CREATED や PULL_REQUEST_UPDATED など）がトリガーとして設定されていないかをチェックします。

#!/bin/bash

# チェックしたいAWSリージョンを指定（必要に応じて変更してください）
REGION="us-west-2"

# 指定リージョンのCodeBuildプロジェクト名一覧をJSONからjqで抽出
PROJECTS=$(aws codebuild list-projects --region "$REGION" --output json | jq -r '.projects[]')

# プロジェクトが存在しなければ処理を終了
if [ -z "$PROJECTS" ]; then
  echo "[$REGION] 対象のCodeBuildプロジェクトがありません。"
  exit 0
fi

# PRビルドトリガー設定があるプロジェクトを検出した場合のフラグ
FOUND_PR_TRIGGER=0

# 各プロジェクトをループで処理
for proj in $PROJECTS; do
  echo "Check: ${proj}..."

  # プロジェクトの詳細情報を取得（Webhook設定含む）
  details=$(aws codebuild batch-get-projects --region "$REGION" --names "$proj" --output json)
  
  # Webhookが設定されているか判定
  has_webhook=$(echo "$details" | jq '.projects[0].webhook != null')
  
  if [ "$has_webhook" = "true" ]; then
    # WebhookのfilterGroups配列からtype="EVENT"のpatternを抽出
    event_patterns=$(echo "$details" | jq -r '
      if (.projects[0].webhook.filterGroups == null) then 
        empty 
      else 
        .projects[0].webhook.filterGroups[][] | select(.type=="EVENT") | .pattern 
      end')
    
    # もしイベントパターンにプルリクエスト関連のものが入っていたら
    if echo "$event_patterns" | grep -q -E 'PULL_REQUEST_CREATED|PULL_REQUEST_UPDATED|PULL_REQUEST_REOPENED|PULL_REQUEST_MERGED|PULL_REQUEST_CLOSED'; then
      echo "問題あり: プロジェクト '$proj' にPRビルドトリガー設定があります。"
      echo "  トリガーイベント: $event_patterns"
      echo ""
      FOUND_PR_TRIGGER=1
    fi
  fi
done

# 1つも検出していなければ問題ない旨を表示
if [ $FOUND_PR_TRIGGER -eq 0 ]; then
  echo "問題なし: PRビルドの自動トリガー設定はありません。"
  echo "今回の通知に関連するWebhookリスクは現時点で確認されません。"
fi

具体的なスクリプトのロジックは、以下のようになっています。

  • まず、AWS CLIのlist-projectsコマンドで指定リージョン内の全CodeBuildプロジェクト一覧を取得し、続いてbatch-get-projectsで各プロジェクトの詳細情報を取得します。
  • 取得したJSONデータから、jq を駆使してWebhookが設定されているかを確認し、設定されている場合はそのfilterGroups内のtype="EVENT"のpatternを抽出します。
  • そのパターンの中に、PULL_REQUEST_CREATED、PULL_REQUEST_UPDATED、PULL_REQUEST_REOPENED、PULL_REQUEST_MERGED、PULL_REQUEST_CLOSED といったプルリクエスト関連イベントの正規表現に合致する文字列が含まれていないかを厳しく判定。
  • もし一つでもPRビルドトリガーが検出されたら「問題あり」と表示し、そのプロジェクト名とトリガーイベントを報告。全て問題なければ、最後に「問題なし」と表示する仕組みです。

さて、気になる結果ですが…

./check_codebuild.sh
...
問題なし: PRビルドの自動トリガー設定はありません。
今回の通知に関連するWebhookリスクは現時点で確認されません。

と表示されれば問題ありません。
但し、リージョン毎の確認が必要なので注意してください。

対応

もしチェックスクリプトで問題が発見された場合は以下の対応をご検討ください。

  1. WebhookイベントフィルターからPR関連イベントを除外する

    AWSマネジメントコンソールのCodeBuildプロジェクト設定画面で「Primary source webhook events」から「Pull request」関連イベントのチェックを外す。

    またはAWS CLIでWebhookのfilterGroupsを編集し"pattern": "PULL_REQUEST_*"の項目を削除、もしくはfilterGroupsをPUSHイベントのみに限定する。

  2. 信頼できるユーザーのみビルドを許可するフィルター設定を追加する
    filterGroupsにACTOR_ACCOUNT_IDタイプのフィルターを設定し、信頼できるGitHubアカウントIDなどに限定する。

    これにより、未信用者のPRはトリガーされなくなりリスクが軽減。

  3. Webhook自体を無効化または一時停止する
    不要なWebhookやPRビルドトリガーは無効化し、リスクのもとを断つ。

  4. アクセストークンのローテーションを実施する
    もしPRイベントを含んだWebhookが長期間存在していた場合は、念のためにリポジトリアクセストークンのローテーションを実施し、古いアクセストークンの無効化を行う。

  5. 継続した監視・運用ルールの強化
    今後もWebhookイベント設定の定期的な検査や、トークン使用の監査を運用ルールとして組み込む。

終わりに

AWS CodeBuild の自動 PR ビルド設定に対するリスクを早期に認識し、今回の綿密な調査を行いました。結果的に問題は確認されませんでしたが、この手のセキュリティは常にアンテナを張って、最新の情報を反映していくことが本当に重要だと改めて感じました。

一言

この記事が良かったと少しでも思って頂けたら、ぜひ @___nix___ をフォローしてあげてください！今後の執筆の励みになります。

Discussion