audit-xcode-security-settings

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

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

ツールの優先順位

XcodeGlob、XcodeGrep、XcodeRead、XcodeLS、XcodeUpdate ツールが利用可能な場合は、常にそれらを使用してください。プロジェクトについて調べるために Bash のファイルシステムツール（ls、find、cat、grep）にフォールバックしないでください。これらは余分な権限プロンプトを引き起こし、プロジェクトのスコープを回避します。

ツール名には MCP サーバーのプレフィックスが付く場合があります。 これらのツールは、環境によって名前が異なる MCP サーバー（xcode-mcp、xcode-tools、xcode など）によってホストされているため、完全修飾名は mcp__<server>__XcodeGlob のようになります。一部のハーネスは短いエイリアス（単に XcodeGlob）を登録しますが、プレフィックス付きの形式しか公開しないものもあります。特定のサーバー名をハードコードしないでください。最初の呼び出しでは、利用可能なツールのレジストリが通知する形式を使用してください。プレフィックスを一度調べ、その後はセッションの残りの間それを再利用します。短い名前での呼び出しが unknown-tool エラーで失敗した場合、プレフィックスを推測しないでください。レジストリで調べ、完全な名前で再試行してください。

• XcodeGlob はファイルの検索に使用します — プロジェクト内のファイルに対して find は禁止です。
• XcodeGrep はコンテンツの検索に使用します — プロジェクト内のファイルに対して grep/rg は禁止です。
• XcodeRead はファイルの内容の読み取りに使用します — プロジェクトに登録されたファイルに対して cat/Read は禁止です。
• XcodeLS はディレクトリの一覧表示に使用します — プロジェクト内のあらゆるパスに対して ls は禁止です。
• XcodeUpdate は、プロジェクトに登録されたテキストファイル（xcconfig ファイル、ソースファイル）のその場での編集に使用します — 組み込みの Edit ツールと同じ filePath / oldString / newString（+ 任意の replaceAll）シグネチャですが、Xcode ワークスペース相対のパスを受け付けます。プロジェクトに登録されたファイルに対して Edit は禁止です。.entitlements のキーを追加または更新するために XcodeUpdate / Edit / plutil を使用しないでください — AddEntitlement を使用してください。
• AddEntitlement は、ターゲットのエンタイトルメントを追加または更新するために使用します — targetName、entitlementKey、entitlementValueType（bool / string / int / stringArray / dictionary）、および値を渡します。エンタイトルメントの変更には常にこれを優先してください。これは追加または更新のみを行い、キーを削除することはできません。
• XcodeListTargets はターゲットを列挙するために使用します — project.pbxproj を手動で解析しないでください。各ターゲットの PRODUCT_TYPE_IDENTIFIER とロールフラグ（IS_AGGREGATE、IS_TEST_TARGET、IS_APP_EXTENSION、SUPPORTS_HOSTING_TESTS）を直接返します。

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

XcodeGlob の結果が空でも失敗ではありません。 .xcodeproj と .xcworkspace は Xcode ワークスペース内のファイルとしてインデックス化されていません — XcodeGlob "**/*.xcodeproj" は正しく 0 件を返します。代わりにシステムプロンプトのコンテキストにあるプロジェクト名を使用してください。ファイルシステムの ls/find にフォールバックしないでください。

すべての Xcode* ツールは Xcode ワークスペース相対のパスを受け取ります。 XcodeGlob、XcodeGrep、XcodeRead、XcodeLS、XcodeUpdate、XcodeWrite、XcodeRM は、パス引数を Xcode ワークスペースのルート（Project Navigator の先頭に表示されるもの）を基準に解釈し、パスもその基準で返します。git リポジトリのルートでも、.xcodeproj バンドルでもありません。ユーザーが Xcode で見るもの（エンタイトルメント、xcconfig、計画および決定のドキュメント、ソースファイル）は、そのワークスペース相対パスを介して到達可能です。そのパスをそのままこれらのツールに渡し、それに対して絶対ファイルシステムパスを構築しないでください。

特定のファイルを読み取る、または編集するには：

• ワークスペース相対パスを指定して XcodeRead / XcodeUpdate を優先してください。XcodeRead は .entitlements plist も読み取ります — これらはプロジェクトに登録されたファイルであり、他のソースファイルと同様にナビゲートできるため、この方法で読み取ってください。エンタイトルメントを追加または更新するには、XcodeUpdate ではなく AddEntitlement を使用してください。 entitlements ファイルについては、パスを手作業で導出しないでください。 各ターゲットの正式な entitlements パスは、その CODE_SIGN_ENTITLEMENTS ビルド設定を評価した値です。GetTargetBuildSettings から取得し、そのまま使用してください。パスを再構築するために project.pbxproj を解析したり、**/*.entitlements を glob したりしないでください。どのターゲットからも参照されていない孤立した .entitlements ファイルがディスク上に存在する可能性があります。1 つの entitlements ファイルが複数のターゲットから参照されることもあります。

Bash へのフォールバックは、Xcode ツールでは実行できない操作（例: git 操作）に限って行ってください。

同梱のリファレンスドキュメント

すべてのリファレンス資料は、このファイルと同じ階層にある references/ の下に配置されています。

• references/security-settings-reference.md — このスキルが追跡するセキュリティビルド設定と entitlements の正規リスト。強化された値、CLI フラグ、言語スコープを含みます。
• references/reading-build-settings.md — GetTargetBuildSettings のスキーマ、フィルタースクリプトのレシピ、監査テーブルの構築、および「すでに強化済み」/「意図的に無効化」の述語。
• references/enhanced-security.md — Enhanced Security 機能: ビルド設定、entitlements、サポートされるプロダクトタイプ。
• references/pointer-authentication.md — arm64e ポインタ署名: サポートされるプラットフォーム、コンシューマー側の互換性に関する注意事項。
• references/universal-binaries-for-libraries.md — ライブラリ/フレームワークターゲット向けのユニバーサルバイナリのガイダンス（ポインタ認証により arm64e スライスが自動的に追加されます）、対象となるプロダクトタイプ、XCFramework のガイダンス。
• references/security-compiler-warnings.md — Enhanced Security によって有効化される、セキュリティに焦点を当てたコンパイラ警告と設定。
• references/cpp-hardening.md — C++ 標準ライブラリの強化（CLANG_CXX_STANDARD_LIBRARY_HARDENING）と境界安全なバッファ（ENABLE_CPLUSPLUS_BOUNDS_SAFE_BUFFERS）。
• references/typed-allocators.md — 型を考慮したアロケータのサポートと hardened-heap サブオプション。
• references/stack-zero-init.md — 実行時のスタック変数の自動ゼロ初期化。
• references/readonly-platform-memory.md — dyld 状態の読み取り専用保護。
• references/runtime-restrictions.md — dylib および Mach メッセージのプラットフォーム制限。
• references/hardware-memory-tagging.md — MTE entitlements とサポートされるハードウェア。
• references/checked-pointer-arithmetic.md — Checked Pointer Arithmetic（CPA2）。
• references/additional-settings.md — デフォルトを超えるオプトインの診断設定（誤検出が増える可能性があります）。
• references/adoption-strategy.md — Enhanced Security 機能を検証するための推奨順序（リスクが最も低いものから労力が最も大きいものへ）。
• references/decision-document.md — 永続的な xcode-security-settings.md 決定ドキュメントを維持する方法。

このスキルには 1 つのヘルパースクリプトが同梱されています:

• scripts/filter_build_settings.py — GetTargetBuildSettings の JSON を、security-settings-reference.md で追跡されているマクロにフィルタリングします。使用方法については references/reading-build-settings.md を参照してください。

よくある失敗パターン

症状	原因	正しい対応
XcodeGlob などに対してツール呼び出しが "unknown tool" / "tool not found" で失敗する	この環境では、ハーネスがこれらのツールを完全な MCP プレフィックス名 (mcp__<server>__XcodeGlob) でのみ登録している	利用可能なツールのレジストリでプレフィックスを調べ、完全な名前で一度再試行し、その後はセッションの残りの間、完全な名前を使用します。
XcodeGlob "**/*.xcodeproj" が 0 件の一致を返す	.xcodeproj 自体はプロジェクトにインデックスされたファイルではない	システムコンテキストからプロジェクト名を使用します。find や ls にフォールバックしないでください
.xcodeproj / .xcworkspace バンドル内に実際に存在するファイル (例: WorkspaceSettings.xcsettings) に対して XcodeRead <workspace-relative-path> が失敗する	そのファイルはプロジェクトナビゲータのメンバーではない	システムコンテキストのプロジェクトルートを使ってファイルシステムの絶対パスに変換し、Read / Edit を使用します。(.entitlements ファイルには適用されません — これらはナビゲート可能です。)
手動で導出した entitlements パスに対する Read が File does not exist を返す	そのパスは project.pbxproj のグループネストから再構築されたか、**/*.entitlements のグロブで推測されたものである。ターゲットの entitlements に対する Xcode の正式なパスは、ナビゲータが表示するものではなく、CODE_SIGN_ENTITLEMENTS の評価値です。	GetTargetBuildSettings を介してターゲットの CODE_SIGN_ENTITLEMENTS を調べ (または監査テーブルから読み取り)、その評価値をパスとして使用します。

ワークフロー

フェーズ 1: ブリーフィング

作業を始める前に、このスキルが何であるか、何を行うか、そしてユーザーの時間と注意力がどの程度必要になるかを、2〜3 文でユーザーに伝えてください。

• 何であるか。 プロジェクトの Xcode セキュリティビルド設定とエンタイトルメントの監査です（コンパイラ警告、Enhanced Security エンタイトルメント、ポインタ認証、チェック付きポインタ演算、ライブラリのユニバーサルバイナリなど）。
• 何が起こるか。 このスキルはほぼ同じ長さの 2 つのパートで実行されます。まず プランニング: プロジェクトを分析し、レビュー用にプロジェクトルートへ編集可能なプランファイルを書き出します。次に 実行: ユーザーが Run を選ぶと、承認された変更のみを適用します。Run を選ぶまで何も変更されません。
• 所要時間。 プランニング は数分間の分析（ターゲットが多いプロジェクトではより長くなります — 進捗を随時お伝えします）に加えて、プランファイルのレビューです。レビューは手早く済ませることもじっくり行うこともできます — お任せします。実行 もほぼ同じくらいの時間がかかります: 承認された変更の適用で、ユーザーの入力を待って一時停止する可能性がある箇所が 2 つあります — 問い合わせステップ（意図的に無効化されている設定で、その理由が文書化されていない場合）と、プランファイルを記録としてプロジェクトに残すかどうかの最終的な yes/no です。 通常、全体で 15〜30 分程度かかり、2 つのパートにほぼ均等に分かれます。ビルドターゲットの数と、プランのレビューと承認にかかる時間によって変わります。

簡潔に保ってください — ユーザーは監査を望んでいることを承知のうえでこのスキルを呼び出しています。 ブリーフィングは、現実的な期待を持ってもらうために存在します。

次にソース管理の有無を確認します。 次のいずれかに該当する場合、プロジェクトには ソース管理 があります:

• Environment ブロックの Is a git repository フィールドが true である、または
• プロジェクトルートでの 1 回のファイルシステムチェックで .git、.hg、.svn、.bzr、.fslckout、_FOSSIL_、CVS のいずれかが見つかる。

それ以外の場合、プロジェクトには ソース管理がありません。この状態を記録してください — フェーズ 4 ステップ 3 でこれを使用し、プランファイルに ⚠️ ブロッククォートを含めるかどうかを判断します。

ブリーフィングを伝えた後、AskUserQuestion で一時停止します。プロジェクトにソース管理がある場合:

• 監査を開始 — フェーズ 2 へ進みます。
• キャンセル — 「キャンセルしました — 変更は適用されていません。」と出力して終了します。

プロジェクトに ソース管理がない 場合は、まずユーザーに伝えてください: 「続行する前にソース管理を設定することを強くお勧めします。このスキルはビルド設定とエンタイトルメントを変更します。Git のようなものがないと、ロールバックには手動での取り消しが必要になり、差分を確認するクリーンな方法がありません。Xcode には Source control management の組み込みサポートがあります」 その後、次のように尋ねます:

• 先にソース管理を設定する（推奨） — 「ソース管理を設定 してスキルを再実行してください。」と出力して終了します。
• ソース管理なしで続行 — フェーズ 2 へ進みます。フェーズ 4 ステップ 3 で、ソース管理がない場合のリマインダーがプランファイル内に再び表示されます。
• キャンセル — 「キャンセルしました — 変更は適用されていません。」と出力して終了します。

この一時停止は、ブリーフィングが読める程度の時間だけ画面に留まるために存在します。そうしないと、Discovery と Analysis の出力によってスクロールして見えなくなってしまいます。ソース管理がないときに早い段階で失敗させることで、何分もかけてディスカバリと分析を行った末に、プラン承認の段階でユーザーが離脱してしまうのを避けられます。

フェーズ 2: ディスカバリ

システムプロンプト内の Environment ブロックを読み取ってください。関連するフィールド:

• Primary working directory — プロジェクトルート（プロジェクト名はベース名です）。
• Is a git repository — プロジェクトが git で追跡されているかどうか（フェーズ 1 のソース管理チェックで使用されます）。

進捗の追跡

実行が必要なターゲット単位 / 設定単位のアクションはすべて、透明性のためにそれぞれ独自のタスクを持つ必要があります。

• フェーズ 1(ブリーフィング)は、ユーザーが「監査を開始」/「キャンセル」を選択したときに完了する 1 つのタスクです。
• フェーズ 3 は、ターゲットごとに 1 つのタスク(Audit <target>)を作成します。このタスクは、フェーズ 3 がターゲットごとの監査テーブル行と(サポートされている製品タイプの場合)そのターゲットの Enhanced-Security カテゴリの両方を生成した時点でクローズされます。フェーズ 3 は、ターゲットごとのすべての状態をタスクの description フィールドに保存し(形式についてはフェーズ 3 のステップ 4 を参照)、後のフェーズが TaskGet を介してそれを読み戻せるようにします。フェーズ 4〜7 はこれらのタスクの description を読み取ります。
• フェーズ 4(計画と承認)は、ユーザーが「実行」/「キャンセル」を選択したときに完了する 1 つのタスクです。
• 「実行」時、フェーズ 4 のステップ 5 は計画を解析し、細かいタスクを作成します。各適用タスクに対して、そのターゲットの差分(対応する Audit <target> タスクの description から抽出)を適用タスク自身の description に埋め込むため、フェーズ 5 はそれを再度参照する必要がありません。
  • チェックされている各 Enhanced Security サブ項目について:
    • Enable Enhanced Security: Enable Enhanced Security at project level(1 つのタスク)。pbxproj のみのプロジェクトでは、このタスクはフェーズ 5 のステップ 1a で説明されているガイドと検証のフローを内包します。
    • Update entitlements: 変更が必要なターゲットごとに 1 つの Apply Enhanced Security entitlements to <target>。
    • Hardware memory tagging: Apply Hardware Memory Tagging(1 つのタスク。サポートされているターゲットを内部的に巡回します)。
    • Checked pointer arithmetic: Apply Checked Pointer Arithmetic(1 つのタスク。サポートされているターゲットを内部的に巡回します)。
  • チェックされている各 Warnings サブ項目について:
    • そのサブ項目がチェックされている場合は Apply Compiler Warnings。
    • そのサブ項目がチェックされている場合は Apply Static Analyzer Warnings。
    • そのサブ項目がチェックされている場合は Apply Clang-Tidy Warnings。
  • チェックされている場合は Apply Additional Diagnostic Settings。
  • チェックされている場合は Emit Bounds Safety Adoption guidance。
  • フェーズ 6 の候補ごとに 1 つの Inquire about <MACRO> on <target>(「無効化された設定について確認する」がチェックされている場合のみ)。
  • Report and update decision document。
  • Prompt to remove plan file — 常に最後。エラーパスでも発火します。

各フェーズまたはサブステップに入るとき:

• フェーズまたはサブステップの名前を平易な英語で 1 行出力します — フェーズ番号は決して出力しません。フェーズの名前を使用します(例: 「▶ Briefing」、「▶ Analyzing project」、「▶ Plan & Approve」、「▶ Applying settings」)。サブステップの場合は、何を行っているかを名付けます(例: 「▶ Detecting languages」、「▶ Building the audit table」)。
• タスクを in_progress に更新します。

各フェーズまたはサブステップを終えるとき:

• 1 行出力します: 「✓ <同じラベル>」。該当する場合は簡単な結果を添えます(例: 「✓ Detecting languages: C and Swift found.」)。
• タスクを completed に更新します。

適用ステップは、完了する前に、自分が行ったことを自身のタスクの description にターゲットごとに 1 行で記録してもかまいません。フェーズ 7 は、状態を再導出したり以前の出力をスクレイピングしたりする代わりに、それらの行を読み取ります。

フェーズ 3: プロジェクトと設定の分析

ユーザーとの対話はありません。バックグラウンドで事実を収集します。

ステップ 1: 既存の意思決定ドキュメントを特定する

XcodeGlob '**/xcode-security-settings.md'。見つかった場合は、XcodeRead でそれを読み取り、言語 + 以前の設定の決定をそのステータスと根拠とともに抽出します。これは以降のフェーズに情報を提供します。

ステップ 2: 言語を検出する

言語ごとに 1 つの XcodeGlob を実行します。結果が空でも失敗ではありません。その言語が存在しないものとして記録します。

• **/*.c → C
• **/*.cpp、**/*.cxx、**/*.cc → C++
• **/*.m → Objective-C
• **/*.mm → Objective-C++
• **/*.swift → Swift

Objective-C++ は C++ が存在することを意味します。 .mm ファイルには C++ のソースコードが含まれるため、「C++ が存在する」ことを条件とするあらゆる監査（C++ 標準ライブラリの堅牢化、bounds-safe-buffers のガイダンス、CLANG_ANALYZER_OSOBJECT_C_STYLE_CAST など）は、.cpp/.cxx/.cc ファイルが存在しない場合でも、Objective-C++ が検出された時点で実行する必要があります。

ファイル名の拡張子は決定的な根拠ではありません。 Xcode プロジェクトでは、project.pbxproj 内の explicitFileType / lastKnownFileType によってファイルのコンパイル言語を上書きできます。最も一般的なのは、.m ファイルが sourcecode.cpp.objcpp（Objective-C++ としてコンパイル）と指定されているケース、または .h が sourcecode.c.h / sourcecode.cpp.h と指定されているケースです。これらの上書きを検出するには、Bash 経由で grep -E 'sourcecode\.cpp\.[a-zA-Z0-9]+' <project-root>/<ProjectName>.xcodeproj/project.pbxproj を実行します。project.pbxproj は .xcodeproj バンドル内にある Xcode のプロジェクト記述ファイルです。直接読み取ってください。sourcecode.cpp.objcpp に一致するものは Objective-C++ と C++ の両方として扱い、その他の sourcecode.cpp.* に一致するものは C++ として扱います。

ステップ 3: 監査テーブルを構築する

列の定義、構築手順、および正規の述語（「すでに堅牢化済み」、「デフォルトで OFF」、「意図的に無効化」）については references/reading-build-settings.md を参照してください。概要は次のとおりです。

1. XcodeListTargets を呼び出してターゲットを列挙します。IS_AGGREGATE = true のエントリ（プロダクトタイプを持ちません）はスキップします。残りの各ターゲットについて TARGET_NAME、CONTAINING_PROJECT、PRODUCT_TYPE_IDENTIFIER を記録します。ステップ 4 では PRODUCT_TYPE_IDENTIFIER によって直接ターゲットを分類します（推測は行いません）。
2. 各ターゲットについて: TaskCreate "Audit <target>" を実行し、in_progress に設定します。GetTargetBuildSettings を呼び出し、得られた JSON に対して scripts/filter_build_settings.py を実行し、追跡対象のマクロごとに evaluatedValue と setAtTargetLevel（JSON に targetValue が存在する場合は yes）を記録します。これらの行は、ステップ 4 でタスクの description に書き込めるよう（カテゴリとあわせて）準備しておきます。タスクは in_progress のままにしておきます。ステップ 4 でクローズします。
3. フィルター正規表現を使った 2 つのパスで明示的な設定をスキャンします: XcodeGrep を *.xcconfig に対して実行し、Bash 経由で grep -nE '<filter regex>' <project-root>/<ProjectName>.xcodeproj/project.pbxproj を実行します。project.pbxproj は .xcodeproj バンドル内にある Xcode のプロジェクト記述ファイルです。直接読み取ってください。マクロごとに numMatchesInXCConfigs、numMatchesInPbxproj、および file:line の引用を記録します。
4. 監査テーブルは結合されたビューです。(target, tracked macro) ごとに 1 行となります。フェーズ 4、5、6 はすべてこのテーブルを利用します。それ以外は再取得しません。

このステップはターゲット数に応じてスケールします。GetTargetBuildSettings の呼び出しにはそれぞれ数秒かかり、ターゲットごとに 1 回実行します。ターゲットがおよそ 10 個以上あるプロジェクトでは、数分かかることがあります。

ステップ 4: ターゲットごとの Enhanced-Security 状態

ステップ 3 で記録した PRODUCT_TYPE_IDENTIFIER によって、各ターゲットを次の 3 つのカテゴリのいずれかに振り分けます。

• Entitlements 対応 — プロダクトタイプが references/enhanced-security.md の「Supported Product Types」リストに含まれる場合（アプリケーション、XPC サービス、システム拡張、ドライバ拡張 [ビルド設定のみ]、ツール）。このターゲットの CODE_SIGN_ENTITLEMENTS ビルド設定に格納されているパスの entitlements plist を読み取り、ターゲットを Up-to-date、Partial、Off、または No-entitlements-file に分類します。複数のターゲットが同じ CODE_SIGN_ENTITLEMENTS パスを共有することがあります。各ターゲットを個別に分類してください。
• ライブラリ/フレームワーク — プロダクトタイプが references/universal-binaries-for-libraries.md に記載されている対象セット（フレームワーク、静的フレームワーク、静的ライブラリ、動的ライブラリ）に含まれる場合。entitlements は読み取りません。フェーズ 5 で、これらに対するユニバーサルバイナリ設定を確認します。
• スキップ — それ以外すべて（テストバンドル、アプリ拡張など）。 次に、Phase 3 がこのターゲットについて学習したすべての内容を、TaskUpdate を介して Audit <target> タスクの description に書き込み、その後、そのタスクを completed に設定します。この description には、Phase 4～6 が後で参照する必要がある、ターゲットごとの状態の全体が保持されます。形式:

Category: <category> [/ <sub-state>]      # e.g. "Entitlements-supported / Partial", "Library/framework", "Skipped"
Entitlements path: <evaluated CODE_SIGN_ENTITLEMENTS>     # omit for Library/framework and Skipped
SDKROOT: <value>
SUPPORTED_PLATFORMS: <value>
Missing entitlements: <comma-separated short names>      # Entitlements-supported only; required and default-ON keys the target lacks; omit if empty
Checked pointer arithmetic: <eligible-entitlement | eligible-slice-only | enabled | not-eligible: <reason>>   # Entitlements-supported and Library/framework targets
Deliberately-disabled: <MACRO>=<value> (<source>[+<source>...]), ...   # one per disabled row; sources ⊆ {target-level, xcconfig, pbxproj} joined with '+' when more than one applies; omit the line entirely if none

Audit table:
  <MACRO>=<value> setAtTargetLevel=<yes|no> numMatchesInXCConfigs=<n> numMatchesInPbxproj=<n> matchLocations=<citations>
  ...

Category 行を先頭に置くことで、スニペットを表示するあらゆるクライアントが意味のある内容を示せるようになります。Audit-table ブロックは、Step 3 で得られた (ターゲット, 追跡対象マクロ) ごとの行を key=value 形式にしたものです。追跡対象マクロごとに 1 行とし、references/reading-build-settings.md で定義されている正規の列名を使用します。matchLocations には、全体で使用されているものと同じ <source>:<file>:<line>[,<line>...] 形式で file:line の引用を記載します。Skipped ターゲットには、この Category 行、プラットフォームフィールド、および Audit-table ブロックが含まれます。Library/framework ターゲットには、それら 3 つに加えて Checked pointer arithmetic: 行が含まれます。どちらも即座に完了します (entitlements は読み取りません)。

Checked pointer arithmetic は、この機能に関する唯一の信頼できる情報源です。 ここで一度だけ計算し、4 つの値のいずれかを記録します。以降のすべてのフェーズはこの行を読み取り、独自のテストは一切適用しません。

• enabled — このターゲットでは何もする必要がありません。Entitlements がサポートされるターゲットの場合: entitlements ファイルに com.apple.security.hardened-process.checked-allocations.enforce-checked-pointer-arithmetic-overflow が含まれており、評価された ENABLE_HARDWARE_CHECKED_POINTER_ARITHMETIC_SLICE が YES です。Library/framework ターゲットの場合: 評価された ENABLE_HARDWARE_CHECKED_POINTER_ARITHMETIC_SLICE が YES です — 確認すべき entitlement はありません。
• not-eligible: <reason> — 次のいずれかです: platform は、SUPPORTED_PLATFORMS / SDKROOT が iphoneos にも watchos にも一致しない場合。opted out は、ENABLE_HARDWARE_CHECKED_POINTER_ARITHMETIC_SLICE がそのターゲットに対して deliberately disabled である場合。no arm64e は、ENABLE_POINTER_AUTHENTICATION が deliberately disabled である場合。outside the capability は、ENABLE_ENHANCED_SECURITY が deliberately disabled である場合。単に at default OFF であるマクロは理由にはなりません — Enhanced Security を有効にすればそれが解除されます。outside the capability は Entitlements がサポートされるターゲットにのみ適用されます: このケイパビリティが entitlement を提供し、ライブラリは何も取りません。
• eligible-entitlement — checked pointer arithmetic を採用でき、まだそれ用に完全に構成されていない Entitlements がサポートされるターゲットです: arm64e.x1 スライス、checked-pointer-arithmetic entitlement、またはその両方が欠けています。Step 4 で、欠けているものを適用します。
• eligible-slice-only — checked pointer arithmetic を採用でき、ビルド設定をまだ持っていない Library/framework ターゲットです。これらのターゲットには entitlement の側面はありません: entitlements はメイン実行可能ファイルからプロセスごとに付与されるため、ライブラリはスライスをビルドし、それを消費するアプリの entitlement がチェックを強制するものになります。Step 4 ではビルド設定のみを適用します。

このキーは Missing entitlements の下に決して記載されません。これは必須かつデフォルトでオンのキーのみを保持するため、ターゲットを Partial にすることはできず、Step 1b に到達することもありません。

大規模なプロジェクトでは、これは多数の .entitlements plist を反復処理します — Step 3 に顕著な時間がかかった場合、これも同様になります。

フェーズ 4: 計画と承認

このフェーズでは、変更が行われる前にユーザーがレビューする、カスタマイズ可能で編集可能な計画ファイルを生成します。承認されると、フェーズ 5～7 はそれ以上のプロンプトなしでエンドツーエンドで実行されます。

ステップ 1: ソース管理の状態

ソース管理はフェーズ 1 で確認済みであり、ユーザーはその時点でソース管理がない状態をすでに受け入れています。フェーズ 4 ステップ 3 では、記録された状態を使用して、計画ファイルに ⚠️ ブロッククォートを含めるかどうかを決定します。

ステップ 2: すべてがすでに構成されている場合はスキップする

Audit <target> タスクを TaskList し、それぞれを TaskGet します。すべてのデフォルトでチェックされたプラン項目がすでに目標状態にある場合は早期終了します。

• すべての Enhanced-Security カテゴリ(各タスクの Category: 行から)が Up-to-date または Skipped である。
• どのタスクの Checked pointer arithmetic: 行も eligible-entitlement または eligible-slice-only と読み取れない。
• すべての関連する Warnings 設定(コンパイラー、静的アナライザー、clang-tidy)が、該当するすべてのターゲットで already hardened である(各タスクの Audit テーブルブロックに従う)。
• どのタスクの Deliberately-disabled: 行も(以下のフェーズ 6 の除外後に)行を生成しない。

オプションのフォローアップ(Additional diagnostic settings、Bounds safety adoption)は早期終了を妨げません。「Everything in scope is already configured」と報告して終了します。プランファイルは書き込まないでください。

ステップ 3: プランファイルを書き込む

XcodeWrite を介して Xcode ワークスペースのルート に xcode-security-audit-plan.md を作成します(パス: xcode-security-audit-plan.md、親グループなし)。XcodeWrite はファイルを <project-root>/ 配下のディスクに書き込むと同時に、プロジェクトに登録するため、ユーザーは Xcode の Project Navigator から直接開くことができます。

プロジェクトに該当する項目のみを含めます(以下の省略ルールを参照)。このテンプレートを使用し、<…> のプレースホルダーを置き換えます。

# Xcode Security Audit — Plan
**Project:** <name> · <N> targets · languages: <list>
**Generated:** <YYYY-MM-DD>
> ⚠️ **No source control detected.** This skill modifies build settings and entitlements.
> Without source control (e.g., Git), rollback requires manual undo. Consider [setting up source control](doc://com.apple.documentation/documentation/xcode/configuring-your-xcode-project-to-use-source-control) before picking **Run**.
Edit the items below — set what steps to perform now, or leave them unchecked to defer them. Questions about any item, or want a more detailed plan? Just ask — I'll answer, and can expand this plan on the points you care about before you decide.
## Phases
- **Enhanced Security** — the project's runtime-protection bundle. Apply to: <target list>. (Group — check the sub-items below.)
  - [x] **[Enable Enhanced Security](doc://com.apple.documentation/documentation/Xcode/enabling-enhanced-security-for-your-app)** — sets `ENABLE_ENHANCED_SECURITY=YES` at the project level. (Your project doesn't use a project-level xcconfig — I'll walk you through enabling it in Xcode's Build Settings UI yourself, then verify by reading project file.)
  - [x] **[Update entitlements](doc://com.apple.documentation/documentation/BundleResources/Entitlements/com.apple.security.hardened-process)** — adds the hardened-process entitlement family per target (Memory Safety, Runtime Protections).
  - [x] **[Hardware memory tagging](doc://com.apple.documentation/documentation/BundleResources/Entitlements/com.apple.security.hardened-process.checked-allocations)** — adds the hardware memory tagging entitlement, in soft mode, on supported platforms (<target list filtered to MTE-supported platforms>).
  - [x] **[Checked pointer arithmetic](doc://com.apple.documentation/documentation/BundleResources/Entitlements/com.apple.security.hardened-process.checked-allocations.enforce-checked-pointer-arithmetic-overflow)** — adds the arm64e.x1 slice and the entitlement to enforce pointer-arithmetic overflow checking (<target list filtered to arm64e.x1-supported platforms>). Run time enforcement requires hardware memory tagging enabled. Latent pointer-arithmetic bugs will terminate the app on capable hardware.
- **[Warnings](doc://com.apple.documentation/documentation/Xcode/build-settings-reference)** — additional diagnostics on all C/C++/ObjC targets. (Group — check the sub-items below.)
  - [x] **Compiler warnings** — <N> settings promoting security-relevant compiler diagnostics (fire on every build).
  - [x] **Static analyzer warnings** — <N> security checkers (run during Build and analyze).
  - [x] **Clang-tidy warnings** — <N> clang-tidy-integrated checks (run during Build and analyze).
- [x] **Inquire about disabled settings** — <M> found (e.g., `<setting>=NO` on `<target>`). May trigger follow-up questions if no rationale is documented.
- [ ] **Additional diagnostic settings** — extra opt-in warnings/checkers beyond the defaults. Off by default: they surface more findings to review and can be noisier (more false positives).
- [ ] **[Bounds safety adoption](https://clang.llvm.org/docs/BoundsSafetyAdoptionGuide.html)** — pointer to a separate skill. No changes applied here.
## Decision document
The skill creates or updates `xcode-security-settings.md` to record every setting decision (kept, deferred, disabled, with rationale). Edit the path to relocate.
- Path: `xcode-security-settings.md`

⚠️ のブロッククォートはプロジェクトにソース管理がない場合にのみ含め、それ以外の場合は省略します。

Enable Enhanced Security サブ項目の末尾の括弧書きは、プロジェクトが pbxproj のみの場合(フェーズ 3 のプロジェクト全体スキャンで *.xcconfig ファイルが検出されなかった場合)にのみ含め、それ以外の場合は省略します。

決定文書は、他のドキュメントと同じディレクトリ、またはプロジェクトレベルに置く必要があります。

項目の省略ルール

プラン項目は、該当しない場合に完全に省略されます。

• Enhanced Security — フェーズ 3 のステップ 4 のすべてのサポート対象製品タイプカテゴリが Up-to-date または Skipped であり、どのタスクの Checked pointer arithmetic: 行も eligible-entitlement または eligible-slice-only と読み取れない場合にのみ省略します(すべてのサブ項目とともに)。それ以外の場合は Enhanced Security を有効にする必要があります。
• Enable Enhanced Security(サブ項目) — Enhanced Security が表示される場合は決して省略しません。末尾の pbxproj のみの括弧書きだけが条件付きの部分です。
• Update entitlements(サブ項目) — Enhanced Security が表示される場合は決して省略しません。
• Hardware memory tagging(サブ項目) — どのターゲットの SUPPORTED_PLATFORMS / SDKROOT も macosx、iphoneos、iphonesimulator、watchos、xros、xrsimulator のいずれにも一致しない場合は省略します。
• Checked pointer arithmetic(サブ項目) — どのタスクの Checked pointer arithmetic: 行も eligible-entitlement または eligible-slice-only と読み取れない場合は省略します。
• Warnings — 純粋な Swift の場合、または 3 つのグループすべてのすべての設定が該当するすべてのターゲットで already hardened である場合は、親項目(および 3 つのサブ項目すべて)を省略します。それ以外の場合は、個々のサブ項目 — Compiler warnings、Static analyzer warnings、Clang-tidy warnings — を、そのグループのすべての設定が該当するすべてのターゲットで already hardened である場合、またはそのグループに検出された言語に対する該当する設定がない場合に省略します。
• Inquire about disabled settings — deliberately disabled 述語が行を生成しない場合は省略します。
• Additional diagnostic settings — 決して省略しません。常に提示されます。
• Bounds safety adoption — フェーズ 3 のステップ 2 で C、C++、または Objective-C++ が検出されなかった場合(sourcecode.cpp.* オーバーライドを C++ としてカウント)は省略します。

デフォルトのチェック状態

グループ見出しにはチェックボックスがありません。 サブ項目を持つ親行 — Enhanced Security と Warnings — は単なる太字のグループラベルであり、チェック可能な項目ではありません。チェックボックスはそのサブ項目に付きます。これにより、サブ項目がすべて未チェックであるのに親がチェックされているという曖昧さを避けられます。それ以外のすべての項目（Inquire about disabled settings、Additional diagnostic settings、Bounds safety adoption のようにサブ項目を持たないリーフ項目も含む）はチェック可能です。

ユーザーは Run を選択する前にプランファイルを編集することで、Phases 配下の項目とサブ項目を切り替えられます。

ステップ 4: 承認を求める

ユーザーに伝えます:

「プランは xcode-security-audit-plan.md に書き込まれ、Xcode プロジェクトに追加されました — 開いて確認してください。必要に応じて編集してください — 項目のチェックを外すか削除するとスキップできます。決定ドキュメントのパスを編集すると再配置できます。準備ができたら Run を選択してください。Cancel を選択すると変更せずに中止します。Run を選択するまで何も変更されません。」

次に AskUserQuestion で単一選択のオプションを使って尋ねます:

• Run — 「フェーズ 5」へ進む
• Cancel — 中止する

ステップ 5: レスポンスを処理する

ユーザーが Run/Cancel を選択する代わりに質問したり、より詳細な説明を求めたりした場合: それに回答し、バンドルされた参照ドキュメント から関連するドキュメントを参照してください (例: 追加の診断設定については references/additional-settings.md)。その詳細を記録に残したい場合は、XcodeUpdate を介して xcode-security-audit-plan.md を更新し、それらの点を詳しく記述してください。その後、ステップ 4 の承認プロンプトを再度提示します — ユーザーが Run を選択するまで何も適用されません。

Cancel の場合: 最終クリーンアップタスク (Prompt to remove plan file、後述の「フェーズ 7: レポートと意思決定ドキュメント」を参照) を実行します。keep-or-remove プロンプトは Cancel 時にも表示されるため、監査を中止するというユーザーの選択が、通常の完了時と黙って異なる扱いになることはありません。「Cancelled — no changes applied」と報告し、スキルを終了します。

再読み込み時にプランファイルが存在しない場合 (ユーザーが応答する前にディスクから削除した場合)、それを Cancel として扱い、Prompt to remove plan file タスクをスキップします (削除するものがありません)。

Run の場合: XcodeRead xcode-security-audit-plan.md。解析します:

• 各 - [x] または - [X] の箇条書きはチェック済み項目です。項目名は太字部分 (**…** の間) です。
• チェックボックスの ない 太字の箇条書き (例: - **Enhanced Security** …、- **Warnings** …) はグループ見出しであり、チェック可能な項目ではありません。それ自体はタスクを生成しません — そのチェック済みサブ項目が作業を駆動します。チェック済みまたは未チェックとして扱わないでください。
• - [ ] として記述された項目およびファイルから削除された項目はスキップされます — どちらも同一のスキップ動作を生じます。
• 「Decision document」見出しの下では、Path: の後の値が意思決定ドキュメントの場所です。

Track Progress に記載された細かいタスクを作成します:

• 各 Apply Enhanced Security entitlements to <target> タスクについて、対応する Audit <target> タスクの説明 (Category:、Entitlements path:、Missing entitlements:) からターゲットごとの差分を apply タスク自身の説明にコピーし、フェーズ 5 が 1 か所から読み取れるようにします。
• Warnings の親行は見出しであり、タスクではありません — それ自体はタスクを生成しません。チェック済みの各 Warnings サブ項目は対応する apply タスクを作成します: Compiler warnings → Apply Compiler Warnings、Static analyzer warnings → Apply Static Analyzer Warnings、Clang-tidy warnings → Apply Clang-Tidy Warnings。これは Enhanced Security の親がそのサブ項目タスクにマッピングされる方法を反映しています。
• Inquire about <MACRO> on <target> タスクを作成するには (Inquire about disabled settings がチェックされている場合のみ)、Audit <target> タスクを TaskList し、それぞれを TaskGet します。各説明の Deliberately-disabled: 行に、そのターゲットの候補行が列挙されています。フィルタリング時には、後述のフェーズ 6 の除外を適用してください。
• Report and update decision document タスクを作成する際は、解析された意思決定ドキュメントのパスをその説明に記載し、フェーズ 7 がそこから読み取れるようにします。

解析されたプランにチェック済み項目が 1 つもない場合は、最終クリーンアップタスクを直ちに実行し、「Plan was empty — nothing to do」と報告します。

フェーズ 5: 設定を適用する

必要に応じて、各 Audit <target> タスクの説明 (Audit テーブルブロック) からビルド設定の状態を読み取ります。ターゲットごとの適用状態は、各 apply タスク自身の説明から取得します。

ビルド設定を適用する方法:

• プロジェクトが .xcconfig ファイルを使用している場合 — xcconfig を直接編集します。プロジェクトレベルとターゲットレベルの両方の設定をサポートします。
• プロジェクトが .pbxproj のみを使用している場合 — ターゲットレベルの設定には UpdateTargetBuildSetting を使用します。ユーザーにプロジェクトレベルの設定を有効化するよう依頼します。ユーザーが設定したと応答したら、プロジェクトファイルに対して grep を使用して正しく設定されたことを検証します。
• 混在している場合 — ターゲットに .xcconfig ファイルがある場合は、xcconfig を編集します。そうでない場合は、Xcode ビルド設定ツールを使用します。新しい構成方法を決して導入しないでください。

ENABLE_ENHANCED_SECURITY は、既存および将来のあらゆるビルドターゲットがこの設定を継承するように、プロジェクトレベルで設定する必要があります。 この設定は、慎重な検討と強力な正当化があった後にのみ無効化すべきです。

ステップ 1: セキュリティ強化

1a. プロジェクトレベルでセキュリティ強化を有効にします。 プロジェクトレベルでセキュリティ強化を有効にする タスクを実行します。その中には 2 つのパスがあります:

• プロジェクトがプロジェクトレベルの xcconfig を使用している場合 — XcodeUpdate を介して xcconfig に ENABLE_ENHANCED_SECURITY = YES を書き込みます。タスクを完了としてマークします。
• プロジェクトが pbxproj のみの場合 — プロジェクトレベルの pbxproj 設定を直接書き込める MCP ツールは存在しないため、ユーザーが Xcode で設定する必要があります。次の正確な手順を提示してください（再表示するときは毎回そのまま繰り返してください）: 「Xcode でプロジェクトを開きます。Project Navigator でプロジェクトを選択します（ターゲットではなく最上位のエントリ）。Build Settings に移動し、スコープを All / Combined に切り替え、ENABLE_ENHANCED_SECURITY を検索し、プロジェクトレベルの列（ターゲット列の左側）を YES に設定します。保存します。」 次に、2 つのオプションを付けて AskUserQuestion を実行します: 有効にしました と 手順をもう一度表示して。有効にしました の場合、Bash で検証します: grep -E 'ENABLE_ENHANCED_SECURITY *= *YES' <project-root>/<ProjectName>.xcodeproj/project.pbxproj。一致が見つかれば、タスクを完了としてマークします。見つからない場合は、先に進まないでください: 変更が実際に行われないまま確認が受け入れられた可能性が高いです — 誤った Enter、または保存のし忘れです。そのことをはっきり伝え、手順をそのまま再表示し、もう一度尋ねます。ループします — 各確認後に grep を再実行し、まだ見つからないたびに手順を再表示します — grep が ENABLE_ENHANCED_SECURITY = YES を見つけるまで。

1b. セキュリティ強化のエンタイトルメントを更新します。 フェーズ 4 のステップ 5 で作成された詳細な Apply Enhanced Security entitlements to <target> タスクは、変更が必要なターゲットをすでに列挙しています（Partial、Off、No-entitlements-file の各カテゴリ — Up-to-date と Skipped は除外されます）。これらのタスクを実行します。

完全なキー一覧、デフォルト値、およびサポートされる製品タイプの一覧については、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
• references/checked-pointer-arithmetic.md — チェック付きポインタ演算（CPA2）

ポインタ認証とバイナリ依存関係。 セキュリティ強化は独立した保護の束であり、arm64e に連鎖するのはポインタ認証のみです。常にプロジェクトレベルで ENABLE_ENHANCED_SECURITY = YES を推奨してください。プロジェクトに、arm64e を提供していないバイナリ Swift Package、xcframework、またはビルド済みフレームワークがある場合、正しい緩和策は、その依存関係をリンクするすべてのターゲットでターゲットレベルの ENABLE_POINTER_AUTHENTICATION = NO を上書きすることです — セキュリティ強化をスキップすることではありません。ユーザーがベンダーに arm64e サポートを依頼し、後で上書きを解除できるように、該当する依存関係をレポートに記載してください。

arm64e.x1 はポインタ認証スライスであるため、ポインタ認証が無効な場所ではビルドすべきではありません。arm64e スライスを提供していないバイナリ依存関係は、arm64e.x1 も提供していない可能性が高いです。ターゲットレベルの ENABLE_POINTER_AUTHENTICATION = NO が設定されるすべてのターゲットで、ターゲットレベルの ENABLE_HARDWARE_CHECKED_POINTER_ARITHMETIC_SLICE = NO も設定してください。ステップ 4 はこれらのターゲットをスキップするため、監査でチェック付きポインタ演算のエンタイトルメントがそこに追加されることはありません。以前の構成からターゲットにすでに com.apple.security.hardened-process.checked-allocations.enforce-checked-pointer-arithmetic-overflow が付与されている場合は、報告してください — ビルド時に、arm64e.x1 がないと効果がないという警告が表示されます。 プロデューサー側 — ライブラリ／フレームワークターゲットでのユニバーサルバイナリ。 ポインタ認証はライブラリおよびフレームワークターゲットでも強く推奨されます — ユニバーサルバイナリはディスク上の成果物が大きくなるという理由で省略しないでください（RAM フットプリントと実行コストは変わりません。dyld は 1 つのスライスのみをロードします）。ポインタ認証を有効にすると、arm64 と arm64e の両方のスライスがすでに自動的にビルドされるため、明示的な ARCHS は不要です。同じ議論はチェック付きポインタ演算にも当てはまり、これには arm64e.x1 スライスを追加する必要があります。arm64e.x1 向けにビルドするコンシューマーがライブラリのコードに対してチェック付き演算を利用できるのは、ライブラリがそのスライスを同梱している場合のみです — コンシューマーアプリは実行時の強制のために他の要件も満たす必要があります。ステップ 4 では、これらのターゲットにビルド設定を適用します。references/universal-binaries-for-libraries.md と references/checked-pointer-arithmetic.md を参照してください。

各タスクについて:

1. 変更セットを構成する — この適用タスクの説明（監査タスクからコピーされた Category: / Missing entitlements: の行）から構成します。

   • Entitlements 対応カテゴリ（Partial / Off / No-entitlements-file）: AddEntitlement を介して entitlements を追加／更新します。存在しない場合は .entitlements を作成し、CODE_SIGN_ENTITLEMENTS を配線します。DriverKit ターゲットはビルド設定のみサポートされます — それらについては entitlements の変更をスキップしてください。
   • Library/framework カテゴリ: entitlements の作業はなく、ビルド設定の変更もありません — ポインタ認証はすでに両方のスライスを出力します。行うべきことは、以下の項目 2 の配布チェックのみです。

2. ターゲットごとのビルド設定。 ENABLE_ENHANCED_SECURITY = YES はすでにプロジェクトレベルで設定されているため（上記のステップ 1a）、ENABLE_POINTER_AUTHENTICATION = YES がすべてのターゲットにカスケードされます。シミュレータービルドにはオーバーライドは不要です — ビルドシステムはシミュレーター SDK に対して arm64e を自動的に除外します。唯一のターゲットごとのオーバーライド: arm64e を同梱していないバイナリ依存関係をリンクする各ターゲットについて、無条件のターゲットレベルの ENABLE_POINTER_AUTHENTICATION = NO を設定します（その依存関係はどのプラットフォームでも arm64e としてリンクできません）。すでに明示的なターゲットレベルの値があるターゲットはスキップしてください（それらの Audit <target> タスク内の Audit-table ブロックに従います）。

   ポインタ認証が最終的に有効になる Library/framework カテゴリの各ターゲット（そのターゲットのプラットフォームが arm64e をサポートしており、既存のターゲットレベルの ENABLE_POINTER_AUTHENTICATION = NO がない場合）については、ビルド設定の変更は不要です — ポインタ認証は arm64e スライスを自動的に追加します。配布ビルドが arm64 と arm64e の両方のスライスを出力することだけを確認してください: ターゲットがその Release／配布構成で ONLY_ACTIVE_ARCH = YES を設定している場合、コンシューマーがシングルアーキテクチャの成果物を受け取ることになる旨をレポートで警告します。

   デフォルトで OFF のサブオプションを自動的に有効にしないでください。ハードウェアメモリタギングはステップ 3 に、チェック付きポインタ演算はステップ 4 に属します。

3. 適用する — ターゲットごとに変更セットを適用します: AddEntitlement で entitlements を追加または更新し（ターゲットに存在しない場合は .entitlements ファイルを作成して CODE_SIGN_ENTITLEMENTS を配線します）、ビルド設定の変更を適用します。

すべてのターゲットを処理した後、レポートします: 「N 個のターゲットで Enhanced Security を有効にしました。arm64e 非対応のバイナリ依存関係をリンクする T 個のターゲットにターゲットレベルの ENABLE_POINTER_AUTHENTICATION = NO を追加しました。U 個のライブラリ／フレームワークターゲットでユニバーサル arm64/arm64e バイナリを出力しました。」プロジェクトが pbxproj のみで、Verify Enhanced Security at project level が成功した場合は、次を追記します: 「Enhanced Security はプロジェクトレベルで有効になっています（Xcode で設定しました）。」ユーザーがガイドのステップをスキップした場合は、次を追記します: 「プロジェクトレベルの ENABLE_ENHANCED_SECURITY は今回の実行では有効になっていません — Xcode で有効にした後、スキルを再実行してください。」

ユーザーは「フェーズ 4」でこれをすでに承認しています — それ以上のプロンプトは不要です。

ターゲットごとの Apply Enhanced Security entitlements タスクは、マルチターゲットプロジェクトにおけるフェーズ 5 の所要時間の大部分を占めます。各タスクはターゲットの .entitlements plist を編集します。

ステップ 2: 警告

純粋な Swift の場合は、このステップ全体をスキップします。このステップでは 3 つのグループを扱い、それぞれが独自のプランのサブ項目で制御されます — コンパイラ警告、静的アナライザー警告、Clang-tidy 警告です。サブ項目がチェックされていない、または削除されているグループはスキップします。各設定について、そのターゲットの Audit <target> タスクの説明（Audit テーブルのブロック）を参照し、行が already hardened である個々の設定はスキップします。それ以外の場合はターゲットレベルで適用します（「ビルド設定の適用方法」を参照）。

コンパイラ警告（毎回のビルドで発火します）:

• GCC_WARN_ABOUT_RETURN_TYPE = YES_ERROR — 値を返さずに戻る非 void 関数は未定義動作です。呼び出し元は戻り値レジスタにたまたま入っていたものを読み取ります。エラーに昇格させることで、これをコンパイル時に捕捉できます。YES_ERROR は「この特定の警告をエラーとして扱う」ための Xcode の正式な値であり、すべての警告をエラーに変えるものではありません。
• GCC_WARN_UNINITIALIZED_AUTOS = YES_AGGRESSIVE — 初期化されていないスタックの値を読み取ると、以前のフレームの内容が漏えいし、攻撃者が古いデータで制御フローを操作できるようになります。アグレッシブモードでは、より多くのケース（例: 条件付きの初期化パス）で警告します。
• CLANG_WARN_IMPLICIT_FALLTHROUGH = YES — 暗黙の switch フォールスルーは、分岐バグの最も一般的な原因の 1 つです。この警告は、意図的な場合に明示的な [[fallthrough]] / __attribute__((fallthrough)) を強制します。
• GCC_WARN_64_TO_32_BIT_CONVERSION = YES — size_t/ポインタから int への暗黙の縮小変換は、整数切り捨て脆弱性の典型的な原因です（長さチェックは広い値では通るものの、狭い値ではフェイルオープンになります）。
• GCC_TREAT_IMPLICIT_FUNCTION_DECLARATIONS_AS_ERRORS = YES（C/ObjC のみ） — 暗黙の宣言は C99 で削除されており、現代の C では誤った呼び出し規約と誤った戻り値型の想定を生み出します。常にエラーです。

2 つの YES_ERROR / … ERRORS = YES 設定にはスコープがあります。すなわち、それ自体の特定の警告だけをエラーに昇格させ、プロジェクト内のすべての警告をエラーにするわけではありません。

静的アナライザー警告（通常のビルドではなく、Build and analyze 中に実行されます）:

• CLANG_ANALYZER_SECURITY_FLOATLOOPCOUNTER = YES — 浮動小数点のループカウンタは、丸め誤差により停止したり行き過ぎたりする可能性があります。アナライザーは、これがセキュリティに関わるバグになり得るループを指摘します。
• CLANG_ANALYZER_SECURITY_INSECUREAPI_RAND = YES — rand() / random() は予測可能な PRNG であり、あらゆるセキュリティ目的に不適切です。アナライザーはその使用を指摘し、呼び出し元が arc4random_uniform や SecRandomCopyBytes に切り替えられるようにします。
• CLANG_ANALYZER_SECURITY_INSECUREAPI_STRCPY = YES — 本質的に安全でない strcpy、strcat などを指摘します。呼び出し元はサイズ制限付きの変種（strlcpy、strlcat、snprintf）に切り替えるべきです。

Clang-tidy 警告（clang 静的アナライザーの一部である clang-tidy 統合チェックです。Build and analyze / clang --analyze 中にのみ発火し、通常のビルドでは決して発火しないため、ビルドを壊すリスクはなく、導入者は追加で何もインストールする必要がありません）:

• CLANG_TIDY_BUGPRONE_REDUNDANT_BRANCH_CONDITION = YES — 外側の条件と重複している分岐条件を指摘します。これはコピー＆ペーストや論理エラーのよくある兆候です。

グループごとに簡潔に報告します。例: 「コンパイラ警告、静的アナライザー警告、clang-tidy 警告を有効化しました。」 — 実際に適用したグループのみを挙げてください。

ステップ 3: ハードウェアメモリタグ付け

ハードウェアメモリタグ付けサブ項目(拡張セキュリティ配下)がオフにされていた、または削除されていた場合は、このステップをスキップしてください。

ハードウェアメモリタグ付けは、SUPPORTED_PLATFORMS(または SDKROOT)が macosx、iphoneos / iphonesimulator、watchos、または xros / xrsimulator であるターゲットでのみサポートされます。 ハードウェアによるバッキングには、A19 チップ以降を搭載した iPhone または iPad、M5 チップ以降を搭載した Mac または Apple Vision Pro、あるいは S11 チップ以降を搭載した Apple Watch が必要です。

references/hardware-memory-tagging.md を読み、サポートされるすべてのターゲットに両方のキーを適用してください: com.apple.security.hardened-process.checked-allocations、および致命的でない段階的展開のためのその soft-mode サブオプションです。ソフトモード単独では何も行いません — これは親キーを置き換えるのではなく修飾するものです。ユーザーは「フェーズ 4」でこれをすでに承認しています — 追加のプロンプトは不要です。

ステップ 4: チェック付きポインタ演算

このステップは、ステップ 1 とステップ 3 のうち実行されたものの後に実行してください: これはステップ 1 が変更しうる設定と、ステップ 3 が追加しうるエンタイトルメントを読み取ります。チェック付きポインタ演算には arm64e.x1 スライスが必要であり、このステップは、ポインタ認証を伴ってすでに arm64e スライスをビルドしているターゲットでのみ、そのスライスを有効にします。実行時強制にはさらに、同じターゲットでのハードウェアメモリタグ付けが必要です。

チェック付きポインタ演算サブ項目がオフにされていた、または削除されていた場合は、このステップをスキップしてください。

Checked pointer arithmetic: 行が eligible-entitlement または eligible-slice-only と表示されているすべてのターゲットに適用し、それ以外はスキップしてください。この行はフェーズ 3 のステップ 4 で計算され、唯一の適格性テストです — ここで再導出しないでください。

次に、ターゲットごとに以下の条件を確認し、各値を新たに読み取ってください: ステップ 1 がビルド設定を変更している可能性があり、ステップ 3 がエンタイトルメントを追加している可能性があります。対象となる条件のいずれかが満たされない場合は、そのターゲットをスキップして報告してください。

• ENABLE_ENHANCED_SECURITY が YES と評価される — eligible-entitlement ターゲットのみ。エンタイトルメントにはこのケイパビリティが必要なためです。
• ENABLE_POINTER_AUTHENTICATION が YES と評価される — 両方の種類のターゲット。arm64e.x1 はポインタ認証スライスであるためです。
• com.apple.security.hardened-process.checked-allocations がエンタイトルメントファイルに存在する — eligible-entitlement ターゲットのみ。実行時強制はハードウェアメモリタグ付けに依存するためです。このキーは、ステップ 3 が実行されなかった、このターゲットをスキップした、またはハードウェアメモリタグ付けサブ項目がオフにされていた場合には存在しません。

実行時強制には、A20 Pro チップ以降を搭載し iOS を実行するデバイス、または S11 チップ以降を搭載し watchOS を実行するデバイスが必要です。

references/checked-pointer-arithmetic.md を読み、ターゲットごとに適用してください。eligible-entitlement ターゲットには、両方の半分を適用します: ターゲットレベルで ENABLE_HARDWARE_CHECKED_POINTER_ARITHMETIC_SLICE = YES を設定し(ターゲットの xcconfig、そうでなければ UpdateTargetBuildSetting)、AddEntitlement で com.apple.security.hardened-process.checked-allocations.enforce-checked-pointer-arithmetic-overflow を追加します。スライス単独ではチェック付きポインタ演算を強制しないため、またターゲットが arm64e.x1 をビルドしていないのにエンタイトルメントが設定されていると Xcode がビルド時に警告するため、両方の半分が必要です。eligible-slice-only ターゲットには、ビルド設定のみを適用してください。

すべてのターゲットの結果を、TaskUpdate を介して Apply Checked Pointer Arithmetic タスクの description に、ターゲットごとに 1 行で記録し、フェーズ 7(レポートと意思決定ドキュメント)が 1 か所から読み取れるようにしてください:

<target>: applied | skipped: <reason>

まったく適格でなかったターゲットには skipped: not eligible — <reason from the target's Checked pointer arithmetic: line> を使用し、適格だったが上記の再読み取りで失敗したターゲットには skipped: ENABLE_ENHANCED_SECURITY is <value>、skipped: ENABLE_POINTER_AUTHENTICATION is <value>、または skipped: no hardware memory tagging entitlement を使用してください。ユーザーは「フェーズ 4」でこれをすでに承認しています — 追加のプロンプトは不要です。

ステップ 5: 追加の診断設定

追加の診断設定 の計画項目がチェックを外されているか削除されている場合は、このステップをスキップします。

references/additional-settings.md を読み、それに従います。ユーザーは「フェーズ 4」でこれをすでに承認しているため、追加のプロンプトは不要です。

ステップ 6: Bounds Safety の導入

Bounds safety の導入 の計画項目がチェックを外されているか削除されている場合は、このステップをスキップします。

このステップは変更を適用しません — ガイダンスを出力するだけです。

C プロジェクトの場合(フェーズ 3 のステップ 2 で C が検出された場合)、次を出力します:

「ENABLE_C_BOUNDS_SAFETY(C 向けのアノテーションベースの Bounds Safety)を導入するには、adopt-c-bounds-safety スキルを呼び出してください。」

C++ プロジェクトの場合(フェーズ 3 のステップ 2 で C++ または Objective-C++ が検出された場合 — 他の拡張子のファイルに対する sourcecode.cpp.* オーバーライドを含む)、次を出力します:

「ENABLE_CPLUSPLUS_BOUNDS_SAFE_BUFFERS(C++ の Bounds-safe バッファパターン)を導入するには、https://clang.llvm.org/docs/SafeBuffers.html のドキュメントを参照してください。」

フェーズ 6: 無効化された設定について確認する

無効化された設定について確認する の計画項目がチェックを外されているか削除されている場合は、このフェーズをスキップします。

このフェーズは、文書化された根拠がない、意図的に無効化された設定ごとに、ユーザーの応答を 1 回待って一時停止します。候補リストが長い場合は、最初に件数を提示して、ユーザーが何を期待すべきか分かるようにします(「意図的に無効化された設定が 7 件見つかりました。それぞれについて確認します」)。

deliberately disabled 述語(references/reading-build-settings.md で定義)が成立する行が候補となります。Audit <target> タスクを TaskList し、それぞれを TaskGet します。各 description の Deliberately-disabled: 行に、そのターゲットの候補行が一覧表示されます。無条件の ENABLE_POINTER_AUTHENTICATION = NO にフラグを立てます。これはデバイスビルドでポインタ認証を無効化するためです。Checked pointer arithmetic: 行が not-eligible: opted out と表示されているターゲットの ENABLE_HARDWARE_CHECKED_POINTER_ARITHMETIC_SLICE = NO にフラグを立てます — この理由は、そのオプトアウトがターゲットと arm64e.x1 スライスの間に立ちはだかる唯一のものであることを意味します。他の not-eligible の理由(そもそもスライスをビルドできなかった場合)ではフラグを立てないでください。フェーズ 3 のステップ 2 で検出された言語を Scope(references/security-settings-reference.md 内)がカバーする設定に限定します。上記の両方の設定には Scope がなく、無条件にフラグが立てられます。

各候補について、フェーズ 4 のステップ 5 で作成された対応する Inquire about <MACRO> on <target> タスクをたどります:

• 決定文書にステータスが Disabled で根拠のあるエントリがある場合 → レポートに記載して次へ進みます。
• そうでない場合 → AskUserQuestion: 「<MACRO> が説明なしで明示的に NO に設定されているのを見つけました。これには理由がありますか?」マクロが deliberately disabled であり、単に Xcode のデフォルトの OFF になっているだけではないことを再確認してください — 明示的なオーバーライドのみを指摘します。根拠を記録します(根拠がない場合は再有効化を推奨します)。

ENABLE_ENHANCED_SECURITY = NO が任意のタスクの Deliberately-disabled: 行に現れる場合も、同じ流れが適用されます。

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

簡潔なサマリーを作成します。

1. 有効化済み — プロジェクト全体で有効化された設定。
2. ターゲットごとのセキュリティ強化 — ターゲットごとに 1 行: 名前、最終ステータス (最新 / 適用済み / ユーザーによりスキップ)、簡潔な差分 (追加されたエンタイトルメント、エンタイトルメントファイルが作成されたかどうか、ターゲットがビルドするようになったスライス、チェック付きポインター演算が適用されたかどうか)。スキップされたターゲットは 1 行にまとめます。チェック付きポインター演算については、TaskGet で Apply Checked Pointer Arithmetic タスクを取得し、そのターゲットごとの結果行を使用します (各スキップの理由も含めます)。
3. すでに有効 — すでに正しく構成されている設定。
4. 確認済み — 無効になっていることが判明した設定と、その確認の結果。
5. アプリをテストする — ユーザー向けのアクション項目: 有効化されたすべてのハードニングをサポートする実機 (シミュレーターではなく) でテストし、保護が発動していないか注意し、発生したクラッシュおよびシミュレートされたクラッシュレポートを修正してください。ハードニングされたアプリが十分にテストされてから初めて顧客に出荷してください。そうしないと、本番環境でクラッシュしたり動作が遅くなったりする可能性があります。特にハードウェアメモリタギングについては、ソフトモードを無効化して強制適用する前に、ソフトモードが生成するシミュレートされたクラッシュレポートを修正してください。チェック付きポインター演算にはソフトモードがなく、メモリタギングのソフトモードもそれをカバーしていないため、出荷前にサポート対象のハードウェアでテストしてください。潜在的なポインター演算のバグはアプリを終了させます。

意思決定ドキュメント。 TaskGet で Report and update decision document タスクを取得し、意思決定ドキュメントのパスを読み取ります。次に references/decision-document.md を読み、それに従ってそのパスにあるドキュメントを作成または更新します。

フェーズ 7 の後 — およびフェーズ 5〜7 中のあらゆるエラーパスでも — この最終タスクが実行されます:

1. Prompt to remove plan file — AskUserQuestion を介してユーザーに尋ねます: 「監査が完了しました。プロジェクトからプランファイル xcode-security-audit-plan.md を削除しますか？」
   • はい、削除します (推奨) → XcodeRM xcode-security-audit-plan.md deleteFiles:true
   • いいえ、残します → そのままにします。承認された内容の記録として Project Navigator に残ります。ユーザーは後から Xcode または Finder で削除できます。

削除に失敗した場合は、ユーザーに警告しますが、終了をブロックしないでください。

ユーザー向けインタラクションのガイドライン

• 返信は簡潔に。 短い文で。
• 完全な文で話す。 断片は使わない。「既存の決定ドキュメントはありません。」のような電報的な名詞句を出力しないでください。完全な文を書いてください（「既存の決定ドキュメントは見つかりませんでした。最後に作成します。」）。
• フェーズは内部的なものです。 ユーザー向けの文章でフェーズ番号やステップ番号を決して参照しないでください。結果を平易に説明してください。「フェーズ 6 の質問はありません」ではなく「無効になっている設定についてお尋ねする必要はありません」と言ってください。これはナレーション、ステータス行、および AskUserQuestion のテキストすべてに当てはまります。
• スキル内部の専門用語は使わない。 ユーザー向けの文章で「カタログ」「監査テーブル」のような言葉を使わないでください。それらはスキル内部のものです。何が起きているかを日常的な Xcode の用語で説明してください。「既知のセキュリティビルド設定を確認しています」「ターゲットの一覧」「今実行した分析」。
• ユーザーへの質問は最小限に。 定められた質問は 3 つです。「フェーズ 1」の最後にあるブリーフィング確認プロンプト（監査を開始 / キャンセル）、「フェーズ 4」の最後にあるプラン承認プロンプト（実行 / キャンセル）、そして「フェーズ 7」の最後にあるプランファイルを保持するか削除するかのプロンプトです。その他の質問は状況に応じたものです。「フェーズ 6」の間に意図的に無効化された設定についての問い合わせ（明示的な = NO に文書化された根拠がない場合のみ）、および Enable Enhanced Security at project level の確認プロンプト（pbxproj のみのプロジェクトで、そのサブ項目がチェックされている場合のみ）。
• 進捗を報告する ことで、ユーザーが追跡できるようにしてください。「有効化しています…」「評価しています…」「保持しています / 元に戻しています…」
• AskUserQuestion を使用する のは、ブリーフィング確認（監査を開始 / キャンセル）、プラン承認（実行 / キャンセル）、「フェーズ 6」の間の無効化された設定についての問い合わせ、フェーズ 5 ステップ 1a の Enable Enhanced Security at project level の確認（pbxproj のみ）、そして「フェーズ 7」の最後にあるプランファイルを保持するか削除するかのプロンプトです。
• 質問をするときは、ユーザーがその質問に答えるために必要なコンテキストを提供してください。たとえば、セキュリティ保護を有効にするかどうかを尋ねる前に、その利点を説明してください。どのように有効にするかではなく、それが提供する保護の観点から説明してください。
• Xcode ビルド設定のリストを出力するときは、箇条書きを使用してください。 カンマ区切りのリストを使わないでください。