SecurityCheck validation rules
Before Speedwave initializes any container topology, it generates the project compose specification and passes it to the SecurityCheck validation engine. SecurityCheck parses the rendered configuration, evaluates it against strict security rules, and inspects host filesystem permissions. If any rule fails, container initialization is halted immediately.
This enforcement mechanism guarantees that runtime environments conform strictly to the architectural constraints outlined in the Isolation model.
Fail-closed startup validation
Section titled “Fail-closed startup validation”SecurityCheck operates on a strict fail-closed model: a single policy violation prevents container startup without bypass flags. Both speedwave and speedwave check enforce this validation in the CLI, while the Desktop application presents a blocking diagnostic overlay. For command syntax, refer to the CLI commands reference.
The standalone speedwave check command inspects configurations and reports detected issues. Standard startup routines attempt automated remediation for standard filesystem permission mismatches. Issues related to file ownership require administrative privileges and prompt the user with explicit manual resolution steps.
Evaluated security rule categories
Section titled “Evaluated security rule categories”The validation suite enforces the credential boundaries detailed in Credentials management. All rules execute comprehensively, aggregating all violations into a consolidated report.
| Rule category | Verification scope |
|---|---|
| Container hardening | All Linux capabilities dropped, privilege escalation prevented, claude/mcp-hub/proxy root filesystems read-only with noexec /tmp mounts |
| Tokens and secrets | claude and mcp-hub reject credential-like environment variables outside a strict allowlist; external LLM provider keys are blocked from claude |
| Network boundaries | Port bindings restricted to 127.0.0.1, container engine sockets blocked from mounts, built-in workers expose zero ports |
| User identity | Containers execute strictly as a designated non-root user |
| Proxy volume profiles | Per-project proxy volume mounts conform exactly to the approved security profile |
| Plugin constraints | Disallow privileged mode and host networking, verify manifest signatures, and validate volume mount allowlists |
| Service profiles (SharePoint, Slack) | Integrations adhere strictly to declared volume profiles without unauthorized mounts |
| Host permissions (Unix only) | Permissions and ownership under ~/.speedwave/ match expected 0o600/0o700 modes |
Host filesystem permission checks are skipped on Windows environments where DACLs govern access. Metadata inspection resolves paths safely without following symlinks.
Violation reporting and remediation
Section titled “Violation reporting and remediation”When violations occur, the diagnostic report identifies the affected container, the violated rule ID, a technical explanation, and actionable remediation steps. Operating system prerequisite checks (such as WSL2 availability on Windows) enforce startup boundaries in the same manner.
Validation scope boundaries
Section titled “Validation scope boundaries”SecurityCheck inspects generated Docker Compose specifications and host storage under ~/.speedwave/. Host-level application features (such as outbound URL validation, host audio capture, and local process sandboxing) are governed by dedicated security controls documented in their respective sections.