Sign In
Appendices · #R

DEML macOS Security Workbench

Reading Progress88%

Appendix R: DEML macOS Security Workbench

native/macos-app is a native Rust desktop surface for local vulnerability triage. It is deliberately local-first: findings, provider configuration, agent results, and audit events stay under the signed-in macOS user's Application Support directory. The state file is written with owner-only permissions. Desktop sessions and model API keys are stored in macOS Keychain, not in the application state file.

Browser authentication

The desktop app uses the existing DEML Firebase login and MFA experience. When the operator selects Continue in browser, the app:

  1. Binds an ephemeral callback listener to 127.0.0.1 only.
  2. Generates a random state value and PKCE verifier/challenge.
  3. Opens deml.app in the default browser with the callback and challenge.
  4. Completes the normal password, phone, Google, Apple, and MFA flow in the browser.
  5. Receives a two-minute, one-time authorization code on the loopback callback.
  6. Exchanges it with the PKCE verifier and stores the resulting 30-day desktop session in macOS Keychain.

The browser never sends a Firebase credential or desktop session through the callback URL. The local listener expires after five minutes, accepts only the exact /callback path, and verifies the state before exchanging the code. On later launches the app validates the saved session with the backend; disabled or deleted users cannot restore a session.

For local web/backend development, set DEML_AUTH_URL and DEML_API_URL before launching the app. Plain HTTP authentication is accepted only for localhost or 127.0.0.1; production authentication must use HTTPS.

Capabilities

  • Sign in through the system browser using the existing DEML account and MFA.
  • Create, prioritize, investigate, mitigate, and resolve local findings.
  • Use Ollama without an API key or configure OpenAI-compatible and Anthropic cloud endpoints.
  • Give the triage agent an explicit list of repository-relative context files.
  • Review a structured remediation plan, proposed commands, and a unified diff.
  • Apply a proposed patch only after an explicit click. The application first runs git apply --check; it never executes model-proposed shell commands.
  • Review a local audit log of security-relevant actions.

Security boundaries

The model receives only the selected finding, the operator's request, and explicitly listed context files. Context paths must resolve inside the selected workspace and are capped at 64 KiB per request. API keys are loaded from Keychain only for the duration of a request. Patch paths are checked for path traversal before git apply is invoked with fixed arguments and patch data on standard input.

This workbench assists an authorized operator; it is not an autonomous scanner or a substitute for change review. Cloud providers receive the supplied prompt and context, so use Ollama for repositories that must remain entirely local.

Run from source

Requirements: macOS, Xcode Command Line Tools, and Rust 1.92 or newer.

cd native/macos-app
cargo run

For local inference, start Ollama separately and select the default http://127.0.0.1:11434 endpoint. The default model is qwen2.5-coder:7b, but any installed chat-capable Ollama model can be entered in Settings.

Install like a normal macOS application

Two installer formats are produced:

  • The .dmg presents DEML Security Workbench.app next to an Applications shortcut. Drag the app onto Applications, eject the image, and launch it from Launchpad, Spotlight, or Finder.
  • The .pkg installs the application directly into /Applications using the standard macOS Installer.

Official releases must be signed with Developer ID, use the hardened runtime, be notarized by Apple, and have the notarization ticket stapled. This gives the same Gatekeeper installation experience expected from applications such as Spotify or Discord.

Build the application and installers

For a local development build:

./scripts/build_macos_installer.sh

Artifacts are written to dist/macos/. Without Apple credentials, the script creates an ad-hoc signed .app, an unsigned .pkg, and a development .dmg. These are suitable for local testing but not public distribution.

For a production release, first create Developer ID Application and Developer ID Installer certificates, then store App Store Connect notarization credentials in a Keychain profile:

xcrun notarytool store-credentials DEML_NOTARY \
  --apple-id "[email protected]" \
  --team-id "YOUR_TEAM_ID" \
  --password "APP_SPECIFIC_PASSWORD"

export DEVELOPER_ID_APPLICATION="Developer ID Application: Example, Inc. (TEAMID)"
export DEVELOPER_ID_INSTALLER="Developer ID Installer: Example, Inc. (TEAMID)"
export APPLE_NOTARY_PROFILE="DEML_NOTARY"
./scripts/build_macos_installer.sh

The script runs the Rust tests and Clippy, builds the branded app bundle, signs it with the hardened runtime, builds both installer formats, submits each to Apple notarization, and staples and validates the returned tickets.