audit-xcode-security-settings

Xcode のセキュリティ設定を監査する

Xcode プロジェクトのセキュリティ状況を評価し、幅広く適用できる警告から Enhanced Security による強化まで、セキュリティのビルド設定とエンタイトルメントを段階的に有効にします。

ツールの優先設定

GetTargetBuildSettings がトークン制限により出力をファイルに保存する場合は、スキーマとフィルタースクリプト（scripts/filter_build_settings.py）について references/reading-build-settings.md を参照してください。保存されたファイルを先頭から順に読み進めないでください。

XcodeGlob、XcodeGrep、XcodeRead、XcodeLS ツールを利用できる場合は、必ず使用してください。プロジェクトについて調べる際に、Bash のファイルシステムツール（ls、find、cat、grep）に切り替えないでください。これらは追加の権限確認を発生させ、プロジェクトのスコープを回避します。

• ファイルの検索には XcodeGlob を使用します。プロジェクト内のファイルに対して find を使用することは禁止されています。
• コンテンツの検索には XcodeGrep を使用します。プロジェクト内のファイルに対して grep／rg を使用することは禁止されています。
• ファイルの内容を読むには XcodeRead を使用します。プロジェクトに登録されているファイルに対して cat／Read を使用することは禁止されています。
• ディレクトリの一覧表示には XcodeLS を使用します。プロジェクト内のパスに対して ls を使用することは禁止されています。

プロジェクトのルートと名前は、すでにシステムプロンプトのコンテキストに含まれています。 作業を始める前に、プロジェクトの構成を「確認」するために ls を実行しないでください。システムプロンプトには、作業ディレクトリとプロジェクト構成がすでに記載されています。

XcodeGlob の結果が空でも、失敗ではありません。 .xcodeproj と .xcworkspace は、Xcode プロジェクト構成内のファイルとしてインデックスされていません。XcodeGlob "**/*.xcodeproj" が一致件数 0 を返すのは正しい動作です。代わりに、システムプロンプトのコンテキストにあるプロジェクト名を使用してください。ファイルシステムの ls／find に切り替えないでください。

プロジェクト構成とファイルシステム間のパス変換。 XcodeGlob は、プロジェクト構成を基準とした相対パスを返します。ファイルの読み取りまたは編集には、次の方法を使用してください。

• XcodeRead／XcodeUpdate でプロジェクト構成上のパスを使用する方法を優先します。
• そのパスが拒否された場合（.entitlements plist など、一部のディスク上のファイルは XcodeRead で参照できないことがあります）、システムコンテキストのプロジェクトルートを先頭に付けて、ファイルシステム上の絶対パスに変換します。ディスク上のパスを探すために find を使用しないでください。

Xcode ツールでは実行できない操作（plist の編集に使う plutil や Git 操作など）に限り、Bash に切り替えてください。

よくある失敗と対処方法

症状	原因	正しい対処方法
XcodeGlob "**/*.xcodeproj" が一致件数 0 を返す	.xcodeproj 自体は、プロジェクトのインデックス対象ファイルではありません	システムコンテキストにあるプロジェクト名を使用し、find や ls に切り替えないでください
設定ファイル（.entitlements、.xcsettings、.xcconfig）に対する XcodeRead <project-org-path> が失敗する	ディスク上の一部のファイルは、プロジェクトパスから参照できません	システムコンテキストのプロジェクトルートを使ってファイルシステム上の絶対パスに変換し、その後 Read／Edit を使用してください

ワークフロー

フェーズ 0：調査

システムプロンプトのコンテキストを読みます。次の情報が含まれています。

• プロジェクトルート（作業ディレクトリ）。
• プロジェクト名と構成（トップレベルのファイル、パッケージ）。
• アクティブなスキーム。

この情報を再確認するために ls、find、またはファイルシステムツールを呼び出さないでください。

進捗の追跡

フェーズ 1 を開始する前に：

1. ワークフローの計画を、ユーザーに見える箇条書きリストとして表示します（詳細を表示しないユーザーにも、これからの作業がわかるようにします）。

   ワークフロー：

   • フェーズ 1：プロジェクトと既存の設定を分析
   • フェーズ 2：設定を適用
     • ステップ 1：拡張セキュリティ
     • ステップ 2：基本的な Clang の安全性警告
   • フェーズ 3：無効になっている設定について確認
   • フェーズ 4：適用した設定を検証
   • フェーズ 5：報告して意思決定ドキュメントを更新
   • フェーズ 6：任意のフォローアップ

2. 同じ項目で TaskCreate を呼び出し、詳細を表示するユーザーが進捗を追跡できるようにします。

各フェーズまたはサブステップの開始時：

• 「▶ Phase N: …」（サブステップの場合は「▶ Phase 2 / Step 1: …」）の形式で 1 行表示します。
• タスクを in_progress に更新します。

各フェーズまたはサブステップの完了時：

• 「✓ Phase N: …」の形式で 1 行表示します（該当する場合は、「✓ Phase 3: 無効になっている設定はありません。」のように、簡潔な結果を添えます）。
• タスクを completed に更新します。

フェーズ 6 は、単一のタスクと単一の行で開始します。ユーザーが特定のフォローアップを選択した場合は、開始時に「▶ Phase 6 / 」、終了時に「✓ Phase 6 / 」と表示し、対応するサブタスクを作成または更新します。

フェーズ 1：プロジェクトと設定を分析

ユーザーとのやり取りは不要です。情報を収集しますが、表示しないでください。利用可能な場合は、Bash の同等機能よりも XcodeGlob、XcodeGrep、XcodeRead を優先してください（「ツールの優先設定」を参照）。

1. XcodeGlob (**/*.xcodeproj) または Glob を使って、.xcodeproj または .xcworkspace を検索します。
2. XcodeGlob または Glob を使って、既存の意思決定ドキュメント (**/xcode-security-settings.md) を検索します。見つかった場合は読み込み、言語、およびこれまでに決定したすべての設定、そのステータスと根拠を抽出します。これらの情報は後続のフェーズで使用します。
3. XcodeGlob または Glob を使って、存在する言語を検出します。
   • **/*.c → C
   • **/*.cpp、**/*.cxx、**/*.cc → C++
   • **/*.m → Objective-C
   • **/*.mm → Objective-C++
   • **/*.swift → Swift
4. ターゲットとそのエンタイトルメントファイルを列挙します。各ターゲットについて、プロダクトタイプ、プラットフォーム（SDKROOT / SUPPORTED_PLATFORMS で確認）、および CODE_SIGN_ENTITLEMENTS を解決したディスク上の .entitlements パス（構成によって異なる場合は構成ごと）を記録します。フェーズ 2 ステップ 1 では、この対応表が必要です。GetTargetBuildSettings を使う場合は、出力スキーマと大きな結果を扱う手順について references/reading-build-settings.md を参照してください。

フェーズ 2：設定を適用

最も適用範囲の広い設定から順に適用します。

既存のセキュリティ設定を確認します。 カタログ内の設定について、pbxproj ファイルと xcconfig ファイルを grep します（references/settings-and-entitlements-catalog.md を参照）。まだ設定されていない項目のみを適用します。すべての設定がすでに有効になっている場合は、その旨をユーザーに伝えて終了します。

ビルド設定の適用方法：

• プロジェクトで .xcconfig ファイルを使用している場合 — xcconfig を直接編集します。プロジェクトレベルとターゲットレベルの両方の設定に対応しています。
• プロジェクトで .pbxproj のみを使用している場合 — ターゲットレベルの設定には UpdateTargetBuildSetting を、プロジェクトレベルの設定には UpdateProjectBuildSetting を使用します。
• 混在している場合 — ターゲットに .xcconfig ファイルがある場合は、その xcconfig を編集します。それ以外の場合は、Xcode のビルド設定ツールを使用します。新しい設定方法を導入してはいけません。

可能な場合はプロジェクトレベルを優先します（重複が少なくなります）。プロジェクトで xcconfig を使用していない場合は、UpdateTargetBuildSetting を使ったターゲットレベルの設定に切り替えます。

例外 — ENABLE_ENHANCED_SECURITY： プロジェクトレベルで設定する必要があります。プロジェクトで xcconfig を使用している場合は、そこで設定します。それ以外の場合は、UpdateProjectBuildSetting を使用します。

ステップ 1：拡張セキュリティ — エンタイトルメントとビルド設定を監査し、ターゲットごとの差分を提案

キーの全一覧、デフォルト値、非推奨キー、バージョン移行、サポート対象の製品タイプについては、references/enhanced-security.md を参照してください。各サブオプションの詳細については、以下を参照してください。

• references/pointer-authentication.md — arm64e ポインター署名
• references/typed-allocators.md — 型を考慮したメモリ割り当て
• references/stack-zero-init.md — スタック変数の自動ゼロ初期化
• references/readonly-platform-memory.md — dyld の状態保護
• references/runtime-restrictions.md — dylib および Mach メッセージの制限
• references/security-compiler-warnings.md — セキュリティ重視のコンパイラ警告
• references/cpp-hardening.md — C++ 標準ライブラリの強化と境界チェック
• references/hardware-memory-tagging.md — ARM MTE

1. サポート対象のターゲットを特定します。 Phase 1 の Step 4 で収集したターゲットマップから、製品タイプが references/enhanced-security.md の「Supported Product Types」一覧にないターゲットを除外します。残ったターゲットを「サポート対象のターゲット」とします。注：DriverKit ターゲットはビルド設定のみがサポート対象です。エンタイトルメントの変更は除外してください。

2. サポート対象の各ターゲットを監査します。 ENABLE_ENHANCED_SECURITY と ENABLE_POINTER_AUTHENTICATION のビルド設定値を収集します（まずターゲットレベルを確認し、次にプロジェクトレベルの継承値を確認します）。DriverKit 以外のターゲットでは、エンタイトルメントファイルも読み込み、非推奨キーを含む com.apple.security.hardened-process* 配下のすべてのキーを収集します。references/enhanced-security.md Part B の必須キーおよびデフォルトで有効なキーと照合し、各ターゲットを次のように分類します。

   • 最新 — 対応は不要です。
   • 一部対応 — ENABLE_ENHANCED_SECURITY が YES であるものの、デフォルトで有効なサブオプションが不足している、非推奨キーがある、またはバージョン "1"／非推奨のバージョンキーが存在します。
   • 無効 — ENABLE_ENHANCED_SECURITY が設定されていません。
   • エンタイトルメントファイルなし — ターゲットはサポート対象ですが、まだ .entitlements ファイルがありません。ユーザーが適用を確認した場合は、ファイルを作成します（Step 5 を参照）。

重要 プロジェクトに、このプロジェクトのソースからビルドされていないバイナリー依存関係（フレームワーク、xcframework、Swift Packages など）がある場合は、ポインター認証を有効にしないでください。そのような依存関係がある場合は、それらを列挙し、arm64 と arm64e の両方を含む Universal バイナリーについて依存関係のベンダーに問い合わせるようユーザーに勧めてください。

3. 変更内容をまとめます。 一部対応または無効のサポート対象ターゲットごとに、次の順序でエンタイトルメントの変更を構成します（空のセクションは省略します）。

   • エンタイトルメントを追加：不足している必須キー（com.apple.security.hardened-process、...enhanced-security-version-string = "2"）と、デフォルトで有効なサブオプションのうち不足しているもの（hardened-heap、dyld-ro、platform-restrictions-string = "2"）を追加します。
   • エンタイトルメントを削除：非推奨キー（...platform-restrictions、...enhanced-security-version）を削除します。
   • エンタイトルメントを更新：バージョン文字列 "1" がある場合は "2" に更新します。

   サポート対象のターゲットに .entitlements ファイルがない 場合は、変更内容にファイルの作成と CODE_SIGN_ENTITLEMENTS の設定を含めます。

   ビルド設定： 上記の「ビルド設定の適用方法」に従ってください。プロジェクトで xcconfig を使用している場合は、プロジェクトレベルの xcconfig で ENABLE_ENHANCED_SECURITY = YES を設定します。そうでない場合は、UpdateProjectBuildSetting を使用します。

   プロジェクトレベルの ENABLE_ENHANCED_SECURITY = YES は、すべてのターゲットに ENABLE_POINTER_AUTHENTICATION = YES を継承させるため、arm64e をサポートしないプラットフォームの各ターゲットには、適用前にターゲットレベルで ENABLE_POINTER_AUTHENTICATION = NO の上書きを設定します（SDKROOT／SUPPORTED_PLATFORMS で判定します）。すでにターゲットレベルで明示的な値が設定されている場合は省略します。

   デフォルトで無効なサブオプション（MTE ファミリー）は自動的に有効にしないでください。状態を報告し、以下の Step 6 で有効化を提案してください。

4. 変更内容を提示して確認を取ります。 サポート対象のすべてのターゲットが最新の場合は、その旨を1行で報告し、Step 2（基本的な Clang 安全性警告）に進みます。適用する変更がない場合は、適用確認を求めないでください。それ以外の場合は、Enhanced Security を有効にする対象として提案するターゲットの一覧を出力します。 次に、Enhanced Security を有効にすることで得られるセキュリティ保護と、必要になる可能性があるコード変更について、簡潔にまとめてください。

   次に、AskUserQuestion を使って一度だけ、次の質問をしてください：「上記の Enhanced Security の変更を適用しますか？」選択肢として「すべて適用」「一部に適用（対象を選択）」「Enhanced Security をスキップ」を提示してください。

5. 適用します。

   • UpdateTargetBuildSetting を使って、arm64e プラットフォームではないターゲットに対し、ターゲットレベルで ENABLE_POINTER_AUTHENTICATION = NO を設定します。ユーザーがすでにターゲットレベルで明示的に値を設定しているターゲットはスキップします。
   • 既存のターゲットごとの .entitlements plist を直接編集し、必須キーとデフォルトで ON のキーを追加し、非推奨のキーを削除し、バージョン文字列 "1" → "2" への移行を一括で行います。
   • .entitlements ファイルがないターゲットにはファイルを作成し、CODE_SIGN_ENTITLEMENTS をそのファイルに設定します。

   次のように報告してください：「Enhanced Security を N 個のターゲットで有効にしました。非推奨の entitlement を M 個削除しました。K 個のターゲットでバージョン文字列を 2 にアップグレードしました。非 arm64e プラットフォームの T 個のターゲットに arm64e オーバーライドを追加しました。」

6. ハードウェアメモリータグ付け。 SUPPORTED_PLATFORMS（または SDKROOT）が macosx、iphoneos / iphonesimulator、または xros / xrsimulator のターゲットのみがサポート対象です。（ハードウェアによるサポートは M5 クラス以降の Apple シリコンです。tvOS、watchOS、DriverKit のターゲットはサポートされていません。）Enhanced Security が適用されていない場合、または変更されたターゲットにこれらのプラットフォームが一つもない場合は、この手順をスキップします。それ以外の場合は、AskUserQuestion を使って次のように質問します：「ハードウェアメモリータグ付けは com.apple.security.hardened-process.checked-allocations で利用できます。有効にしますか？」「はい」の場合 → references/hardware-memory-tagging.md を読み込み、適用します。

Step 2: 基本的な Clang 安全性警告

C、C++、Objective-C、Objective-C++ を含むコードベースでは、確認せずに適用します。Swift のみのコードベースでは、この手順をスキップします。すでに有効になっている設定はスキップします。特に注記がない限り、以下の設定はすべて C/C++/ObjC/ObjC++ に適用されます。

• GCC_WARN_ABOUT_RETURN_TYPE = YES_ERROR
• GCC_WARN_UNINITIALIZED_AUTOS = YES_AGGRESSIVE
• CLANG_WARN_IMPLICIT_FALLTHROUGH = YES
• GCC_WARN_64_TO_32_BIT_CONVERSION = YES
• GCC_TREAT_IMPLICIT_FUNCTION_DECLARATIONS_AS_ERRORS = YES（C/ObjC/ObjC++ のみ）
• CLANG_ANALYZER_SECURITY_FLOATLOOPCOUNTER = YES
• CLANG_ANALYZER_SECURITY_INSECUREAPI_RAND = YES
• CLANG_ANALYZER_SECURITY_INSECUREAPI_STRCPY = YES

簡潔に「追加のコンパイラー警告を有効にしました。」と報告してください。

Phase 3: 無効な設定について確認する

references/settings-and-entitlements-catalog.md にあるビルド設定のうち、明示的に NO に設定されているものがないか、pbxproj ファイルと xcconfig ファイルを Grep します。arm64e をサポートしないプラットフォームのターゲットに対する ENABLE_POINTER_AUTHENTICATION = NO は除外します（このスキル自体がその設定を行います）。arm64e 対応ターゲットの ENABLE_POINTER_AUTHENTICATION = NO は、意図的なオプトアウトとして確認対象にします。ほかに無効な設定が見つからなければ、このフェーズをスキップします。Phase 1 で検出した言語に関連する設定のみを対象とします。カタログの Scope 列を参照してください。

見つかった無効な設定ごとに、意思決定ドキュメントにステータス Disabled と根拠の記載があるか確認します。

意思決定ドキュメントに根拠が記載されている場合は、報告でその根拠に触れて次に進みます。この根拠は過去の判断を記録するものであり、後で再監査できます。

意思決定ドキュメントに記載がない場合は、ユーザーに次のように質問します。

"CLANG_ANALYZER_SECURITY_INSECUREAPI_RAND が明示的に NO に設定されていますが、説明がありません。理由はありますか？"

ユーザーから理由が提示された場合は、それを受け入れ、今後の監査で再評価できるよう、意思決定ドキュメントに根拠を記録します。理由がない場合は、再度有効にすることを推奨します。

これは、ENABLE_ENHANCED_SECURITY など、このスキルが通常有効にする設定にも適用されます。いずれかの設定がすでに明示的に NO に設定されている場合は、同じく意思決定ドキュメントの確認後にユーザーへ問い合わせる手順に従います。

フェーズ 4：設定の検証

フェーズ 2 で変更した各ターゲットについて、GetTargetBuildSettings を使い、適用したすべてのビルド設定が期待どおりの値になっていることを確認します。設定が見つからない場合や、値が想定と異なる場合は、現在の Xcode バージョンでサポートされていない可能性があるものとしてレポートに記載します。出力スキーマと大きな結果を処理する手順については、references/reading-build-settings.md を参照してください。

フェーズ 5：レポートと意思決定ドキュメント

簡潔な概要を作成します。

1. 有効化済み： プロジェクト全体に適用され、有効化された設定を列挙します。
2. ターゲットごとの Enhanced Security： サポート対象の各ターゲットについて、ターゲット名、最終ステータス（最新の状態／適用済み／ユーザーによるスキップ）、簡潔な変更内容（追加したエンタイトルメント、削除した非推奨キー、バージョンの引き上げ、エンタイトルメントファイルを作成したかどうか）を 1 行で記載します。製品タイプがサポート対象外でスキップされたターゲットは、ターゲットごとに記載せず、1 行にまとめます。
3. 有効化済み： すでに正しく設定されていた設定を列挙します。
4. 確認済み： 無効になっていることが判明した設定と、確認結果を記載します。

意思決定ドキュメント。 references/decision-document.md を読み、指示に従って意思決定ドキュメントを作成または更新します。

フェーズ 6：任意の追加手順

以下の順序で、一度に 1 つずつ提案します。それぞれ個別の「はい／いいえ」形式の質問です。選択順の推奨と、言語の構成に基づく判断マトリックスについては、references/adoption-strategy.md を参照してください。

1. 追加の設定。 AskUserQuestion を使って、次のように質問します：「さらに問題を検出できる可能性がある一方で、誤検出が増えることもある診断設定があります。有効にしますか？」はいの場合 → references/additional-settings.md を読み、指示に従います。

2. 境界安全性のプログラミングモデル（C または C++ のコードがある場合のみ）。C プロジェクトでは、次のように質問します：「ENABLE_C_BOUNDS_SAFETY の導入を検討しますか？これは C の境界安全性を実現する、アノテーションベースのプログラミングモデルです。始めるには Xcode の bounds-safety スキルを呼び出してください。」C++ プロジェクトでは、次のように質問します：「ENABLE_CPLUSPLUS_BOUNDS_SAFE_BUFFERS の導入を検討しますか？これにより、C++ で境界安全なバッファーパターンを利用できます。始めるには Xcode の bounds-safety スキルを呼び出してください。」

ユーザー向け対話ガイドライン

• 返信は簡潔にします。 短い文を使います。
• ユーザーへの質問は最小限にします。 予定されている質問は 2 つです。Enhanced Security の適用確認と、ハードウェアによるメモリータグ付けの提案です。その他の質問は状況に応じて行います。意図的に無効化された設定についての確認（明示的な = NO に、文書化された理由がない場合のみ）と、意思決定ドキュメントの保存場所（初回作成時のみ）です。
• 進捗を報告します。 ユーザーが状況を把握できるよう、「有効化中…」「評価中…」「維持／元に戻しています…」と伝えます。
• 無効な設定の確認、Enhanced Security の適用確認（対象を一部に限定する選択肢の提示を含む）、意思決定ドキュメントの保存場所（初回作成時のみ）については、AskUserQuestion を使います。
• 質問する際は、ユーザーが回答するために必要な背景を説明します。 たとえば、有効化するかどうかを尋ねる前に、そのセキュリティ保護の利点を説明します。有効化の手順ではなく、保護によって得られる効果を説明してください。
• Xcode のビルド設定を列挙する場合は、箇条書きを使います。 カンマ区切りの列挙は使いません。