FlutterProbe is a local E2E testing framework for Flutter mobile apps. While it is primarily a developer tool that runs on trusted machines against local or cloud-connected devices, we take security seriously and appreciate responsible disclosure of any vulnerabilities.

Please do not report security vulnerabilities through public GitHub issues.

Instead, use one of the following methods:

1. GitHub Private Vulnerability Reporting (preferred): Navigate to the Security Advisories page and click "Report a vulnerability." This allows for private, coordinated disclosure directly within GitHub.

2. Email: Send details to support@alphawavesystems.com. If possible, encrypt your message using our PGP key (available on request).

When reporting, please include:

• A description of the vulnerability and its potential impact
• Steps to reproduce or a proof of concept
• The version(s) of FlutterProbe affected
• Any suggested remediation, if applicable

We will acknowledge receipt within 48 hours and aim to provide a substantive response within 7 business days. We will work with you to understand the issue and coordinate a fix before any public disclosure.

We kindly ask that you:

• Allow reasonable time for us to address the issue before public disclosure
• Avoid accessing or modifying other users' data
• Act in good faith to avoid degradation of our services

Security fixes are applied to the latest release in each supported minor version series. We recommend always running the latest patch release.

As a public repository, FlutterProbe leverages the following GitHub security features:

Enabled by default for public repositories. The dependency graph identifies all transitive dependencies across the project's three ecosystems:

• Go modules (go.mod) -- CLI and probe-convert tool
• Dart/Flutter (pubspec.yaml) -- ProbeAgent on-device component
• npm (package.json) -- Documentation website (Starlight/Astro)

Dependabot monitors the dependency graph and creates alerts when known vulnerabilities (from the GitHub Advisory Database) affect any dependency. Alerts include severity ratings, affected version ranges, and links to patches.

When a Dependabot alert has a known fix, Dependabot automatically opens a pull request to bump the vulnerable dependency to the minimum patched version. These PRs include compatibility scores and changelog details.

Configured via .github/dependabot.yml, Dependabot opens pull requests to keep dependencies up to date on a weekly schedule. This covers:

• Go modules (root and tools/probe-convert/)
• npm dependencies for the documentation website
• GitHub Actions versions in CI/CD workflows

CodeQL static analysis is free for public repositories. A CodeQL workflow (.github/workflows/codeql.yml) scans all Go code — both the root CLI module and tools/probe-convert/ — on every push to main, on pull requests, and on a weekly schedule. CodeQL detects common vulnerability patterns including SQL injection, path traversal, command injection, and insecure data handling.

Enabled by default for public repositories. GitHub scans all commits for known secret formats (API keys, tokens, credentials) from over 200 service providers.

• Partner alerts: GitHub notifies the issuing service provider so they can revoke compromised credentials
• User alerts: Repository administrators are notified of detected secrets
• Push protection: Blocks pushes that contain high-confidence secret patterns, preventing accidental credential exposure before it reaches the repository

GitHub Security Advisories are used for coordinated vulnerability disclosure. When a vulnerability is confirmed, we create a private advisory, develop a fix, request a CVE (if applicable), and publish the advisory alongside the patched release.

The release workflow produces signed build provenance attestations for all release artifacts. This allows users to verify that binaries were built from the expected source commit in the official CI environment.

The dependency graph supports exporting SPDX-compatible SBOMs, providing a machine-readable inventory of all dependencies for supply chain auditing and compliance.

FlutterProbe includes several security measures in its architecture:

• Bundle ID validation: The project.app field (used in ADB/simctl commands) is validated against the regex ^[a-zA-Z][a-zA-Z0-9_.]*$ at config load time. Invalid values are rejected before any shell interaction.
• Device serial validation: The --device flag value is validated against ^[a-zA-Z0-9._:/-]+$ via config.ValidateDeviceSerial() before being passed to any shell command, preventing command injection.
• Selector sanitization: Selector text captured during recording is sanitized (newlines and control characters stripped) before being written to .probe files, preventing ProbeScript syntax injection.
• iOS path validation: iOS data clearing operations use validateIOSDataPath() to prevent accidental deletion of paths outside the simulator container.

• One-time tokens: The ProbeAgent authentication token is a 32-character cryptographically random string, generated fresh for each session.
• Loopback-only: The WebSocket server (and token exchange) operates exclusively on the loopback interface (127.0.0.1). Tokens are never transmitted over a network.
• Token masking: Dial errors and log messages display ws://host:port/probe?token=*** instead of the actual token value, preventing accidental token leakage in logs or error reports.
• Relay mode security: When using cloud relay mode, connections are automatically upgraded from ws:// to wss:// for non-localhost hosts.

The probe studio interactive UI server implements:

• Localhost binding: The HTTP server binds exclusively to 127.0.0.1, preventing access from other machines on the network.
• CORS protection: API requests from origins other than the Studio's own address (http://127.0.0.1:<port>) are rejected with HTTP 403.
• XSS prevention: All user-controlled content (widget types, keys, error messages) is HTML-escaped via escHtml() before rendering in the DOM.

• The VideoRecorder uses a sync.Mutex to protect shared fields (cmd, segments, frameIdx, remotePath) that are accessed concurrently by background goroutines during screenrecord chaining and screencap capture.

The --adb and --flutter CLI flags (and tools: section in probe.yaml) allow overriding binary paths. These paths are resolved and validated before use, supporting non-standard installations and locked-down CI environments.

All 22 JSON-RPC method names are defined as named constants in both Go (internal/probelink/protocol.go) and Dart (ProbeMethods class). No string literals are used in dispatchers, reducing the risk of typo-driven bugs in the protocol layer.

FlutterProbe maintains minimal dependencies across three ecosystems:

• Go modules: The CLI uses well-established libraries (gorilla/websocket, spf13/cobra, gopkg.in/yaml.v3). Dependencies are pinned via go.sum checksums.
• Dart pub: The ProbeAgent has zero external dependencies beyond the Flutter SDK itself. It uses only flutter/widgets.dart and dart:io from the standard library.
• npm: The documentation website uses Starlight (Astro) with a standard set of Astro plugins. Dependencies are locked via package-lock.json.

Dependabot version updates and security updates are configured to keep all dependencies current. See .github/dependabot.yml for the update schedule.

All security features are active on this repository:

• Dependabot alerts and automatic security updates: enabled
• .github/dependabot.yml: weekly updates for Go modules, npm, and GitHub Actions
• CodeQL (Go): enabled — scans root CLI and tools/probe-convert/ on push/PR/weekly
• Secret scanning with push protection: enabled
• Private vulnerability reporting: enabled
• Branch protection on main: force-push blocked, PR reviews required, CLA check enforced