Only the latest major.minor release line receives active development. The previous line receives security patches for 90 days after a new major release. Critical vulnerabilities are backported to all supported lines.

Do not open a public issue. Use one of these channels:

• GitHub Security Advisory: Go to Security → Advisories → Report a vulnerability on the repo. This is the preferred method — it keeps everything within GitHub's tooling.
• Email: Send details to the repository owner. Include "SECURITY" in the subject line.

Expected response time: 48 hours during weekdays, 72 hours on weekends. You'll receive an acknowledgment, then regular updates as we triage and fix. We'll credit you in the advisory unless you prefer anonymity.

We follow a 90-day responsible disclosure timeline:

1. T+48h: Acknowledgment and initial triage
2. T+30d: Fix merged to main, backported to supported versions
3. T+90d: Public advisory published via GitHub Security Advisories, CVE requested if applicable

If a fix ships earlier, the advisory publishes earlier. If the vulnerability is actively exploited, we'll accelerate the timeline. Extensions beyond 90 days require mutual agreement.

Cyborg-OS is built on a zero-trust execution model. Untrusted code never touches the host.

All code execution runs in disposable Docker containers with these guardrails:

• Cryptographic integrity: Each execution generates a 256-bit ephemeral session token. Output is signed via HMAC-SHA256 by the sandbox wrapper. The host verifies the signature before accepting any data. Tampered output is rejected.
• Full isolation: --network=none, --read-only root filesystem, --cap-drop=ALL, --no-new-privileges
• Resource limits: 256MB RAM, 0.5 CPU, 64 PID max, memory swap disabled, tmpfs mounted noexec
• Non-root: Container runs as UID 65534 (nobody)
• Atomic lifecycle: docker run --rm -i — no persistent containers, no volumes, no lingering state
• Strict mode: CYBORG_STRICT_SANDBOX=true (default) refuses execution if Docker is unavailable. Set to false only in development.

The browser tool (Playwright-based headless browser) is disabled by default (tools.browser.enabled: false). Enable it explicitly in config/cyborg.yaml only if you need live web page interaction. When enabled, it binds to the site being tested — no arbitrary browsing.

The file system tool is restricted to a configurable root directory (tools.file_system.root_dir, default: ./data/workspace). Path traversal outside this root is blocked. All paths are validated against the configured boundary before any read/write operation.

Production deployments should set server.auth_token in config/cyborg.yaml. When configured, all API and WebSocket requests must include the token in the Authorization header. The WebUI dashboard is unauthenticated when auth_enabled: false (development default).

• Lock files committed: If generated by a package manager, lock files live in the repo for reproducible builds
• Dependabot-compatible: Repository is structured for Dependabot to detect outdated dependencies and open PRs automatically
• Regular audits: Run pip-audit or equivalent on the dependency tree before each release
• Pinned versions: Production dependencies are pinned to specific versions; only minor/patch bumps are accepted without review
• Supply chain: Dependencies come from PyPI only. No direct GitHub installs. No unverifiable third-party indexes

Always run untrusted code in Docker. The sandbox is the primary security boundary. Running Cyborg-OS directly on the host (without Docker) is a development convenience — not a production posture.

Keep secrets out of the repo:

• API keys go in .env (gitignored — see .gitignore)
• Use .env.example as a template for required variables
• Never commit credentials, tokens, or signing keys

Production checklist:

1. Set server.auth_enabled: true and configure auth_token
2. Set CYBORG_STRICT_SANDBOX=true (default)
3. Run behind a reverse proxy (nginx, Caddy) with TLS
4. Restrict file_system.root_dir to the narrowest path needed
5. Disable any tools you don't use (tools.*.enabled: false)
6. Use a dedicated non-root host user for the Docker daemon context

Reporting a security issue? See Reporting a Vulnerability above.