Audit Xcode Security Settings

Audit Xcode Security Settings

Assess an Xcode project's security posture and progressively enable security build settings and entitlements — from broadly applicable warnings through Enhanced Security hardening.

Tool Preferences

When GetTargetBuildSettings writes its output to a saved file due to a token limit, see references/reading-build-settings.md for the schema and the filter script (scripts/filter_build_settings.py). Do not read the saved file linearly.

When XcodeGlob, XcodeGrep, XcodeRead, and XcodeLS tools are available, ALWAYS use them. Do not fall back to Bash filesystem tools (ls, find, cat, grep) to learn about the project. They trigger extra permission prompts and bypass project scoping.

• XcodeGlob for file discovery — find is forbidden for files inside the project.
• XcodeGrep for content search — grep/rg is forbidden for files inside the project.
• XcodeRead for file contents — cat/Read is forbidden for files registered in the project.
• XcodeLS for directory listing — ls is forbidden for any path inside the project.

Project root and name are already in the system prompt context. Do NOT run ls to "verify" the project layout before starting. The system prompt already tells you the working directory and the project structure.

Empty XcodeGlob results are not a failure. The .xcodeproj and .xcworkspace are not indexed as files inside the Xcode project organization — XcodeGlob "**/*.xcodeproj" correctly returns 0 matches. Use the project name from system-prompt context instead. Do not fall back to filesystem ls/find.

Path translation between project-org and filesystem. XcodeGlob returns project-org-relative paths. To read or edit a file:

• Prefer XcodeRead / XcodeUpdate with the project-org path.
• If that path is rejected (some on-disk files like .entitlements plists may not be navigable through XcodeRead), translate to a filesystem absolute path by prepending the project root from system context. Do NOT use find to discover the on-disk path.

Fall back to Bash only for operations the Xcode tools cannot do (e.g., plutil for plist editing, git operations).

Common Failure Modes

Workflow

Phase 0: Discovery

Read the system prompt context. It contains:

• The project root (working directory).
• The project name and structure (top-level files, packages).
• The active scheme.

Do not call ls, find, or any filesystem tool to re-discover this information.

Track Progress

Before starting Phase 1:

1. Print the workflow plan to the user as a visible bullet list (so non-verbose users can see what's coming):

Workflow: - Phase 1: Analyze project and existing settings - Phase 2: Apply settings - Step 1: Enhanced Security - Step 2: Basic Clang safety warnings - Phase 3: Inquire about disabled settings - Phase 4: Validate applied settings - Phase 5: Report and update decision document - Phase 6: Optional follow-ups

1. Call TaskCreate with the same items so verbose users get a tracker.

When entering each phase or sub-step:

• Print one line: "▶ Phase N: …" (or "▶ Phase 2 / Step 1: …" for sub-steps).
• Update the task to in_progress.

When finishing each phase or sub-step:

• Print one line: "✓ Phase N: …" (with a brief outcome if applicable, e.g., "✓ Phase 3: No disabled settings found.").
• Update the task to completed.

Phase 6 starts as a single task and a single line. When the user opts into a specific follow-up, print "▶ Phase 6 / <name>" at start and "✓ Phase 6 / <name>" at end, and create/update the corresponding sub-task.

Phase 1: Analyze Project and Settings

No user interaction. Gather facts silently. Prefer XcodeGlob, XcodeGrep, and XcodeRead over Bash equivalents when available (see Tool Preferences).

1. Find .xcodeproj or .xcworkspace via XcodeGlob (**/*.xcodeproj) or Glob.
2. Search for an existing decision document (**/xcode-security-settings.md) via XcodeGlob or Glob. If found, read it and extract: languages and all prior setting decisions with their statuses and rationale. This informs subsequent phases.
3. Detect languages present via XcodeGlob or Glob:

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

1. Enumerate targets and their entitlements files — for each target, record its product type, platform (via SDKROOT / SUPPORTED_PLATFORMS), and resolve CODE_SIGN_ENTITLEMENTS to the on-disk .entitlements path (per configuration if it varies). Phase 2 Step 1 needs this map. When using GetTargetBuildSettings, see references/reading-build-settings.md for the output schema and the recipe for handling large results.

Phase 2: Apply Settings

Apply settings progressively, from most applicable to least.

Check existing security settings. Grep pbxproj and xcconfig files for settings from the catalog (see references/settings-and-entitlements-catalog.md). Only apply settings that aren't already set. If everything is already enabled, tell the user and stop.

How to apply build settings:

• Project uses `.xcconfig` files — edit the xcconfig directly. Supports both project-level and target-level settings.
• Project uses `.pbxproj` only — use UpdateTargetBuildSetting for target-level settings and UpdateProjectBuildSetting for project-level settings.
• Mixed — if a target has an .xcconfig file, edit the xcconfig. Otherwise, use the Xcode build setting tools. Never introduce a new configuration method.

Prefer project-level when possible (less duplication). Fall back to target-level via UpdateTargetBuildSetting when the project doesn't use xcconfig.

Exception — `ENABLE_ENHANCED_SECURITY`: Must be set at project level. If the project uses xcconfig, set it there. Otherwise, use UpdateProjectBuildSetting.

Step 1: Enhanced Security — Audit entitlements + build settings, then propose per-target diffs

Read references/enhanced-security.md for the full key list, defaults, deprecated keys, version migration, and the supported product-type list. For details on individual sub-options, see:

• references/pointer-authentication.md — arm64e pointer signing
• references/typed-allocators.md — type-aware memory allocation
• references/stack-zero-init.md — automatic stack variable zeroing
• references/readonly-platform-memory.md — dyld state protection
• references/runtime-restrictions.md — dylib and Mach message restrictions
• references/security-compiler-warnings.md — security-focused compiler warnings
• references/cpp-hardening.md — C++ stdlib hardening and bounds checking
• references/hardware-memory-tagging.md — ARM MTE

1. Identify suported targets. From the target map gathered in Phase 1 step 4, skip any target whose product type isn't in the "Supported Product Types" list in references/enhanced-security.md. Remaining targets are "supported targets." Note: DriverKit targets are supported for build settings only — skip entitlement changes for them.