Skip to content

Security: faridani/chorus

Security

SECURITY.md

Security Policy

Reporting a vulnerability

Please do not open public GitHub issues for security vulnerabilities.

Report privately via GitHub's "Report a vulnerability" button under the repository's Security tab (Security Advisories → Private vulnerability reporting). If that is unavailable, open a minimal issue asking a maintainer to contact you privately — do not include details in the issue.

Please include:

  • A description of the issue and its impact
  • Steps to reproduce (proof-of-concept if possible)
  • Affected version / commit
  • Any suggested remediation

We aim to acknowledge reports within 5 business days and to provide a remediation timeline after triage. Please give us a reasonable window to release a fix before any public disclosure.

Supported versions

Chorus is pre-1.0 and under active development. Security fixes are applied to the main branch. Pin to a commit you have reviewed for production use.

Security model & operator responsibilities

Chorus orchestrates autonomous coding agents and exposes a local control plane. Operators should understand the following before deploying it:

  • Container boundary. Container mode is strongly recommended because agents run AI CLIs with approval bypasses. The boundary reduces host exposure, but mounted Chorus data, mounted CLI auth directories, forwarded SSH agents, and inherited environment variables remain sensitive.
  • Bare-metal risk. Bare-metal mode gives agent CLI processes the same OS account, filesystem permissions, SSH keys, package managers, and network access that you have. Use a dedicated machine, VM, or OS account.
  • Network binding. Without config/env overrides, the daemon defaults to 0.0.0.0:7878. The example config binds 127.0.0.1, and container launchers publish only 127.0.0.1:7878 on the host by default. For anything beyond a trusted single host, set CHORUS_HOST=127.0.0.1 and put it behind an authenticated reverse proxy or a private overlay (e.g. Tailscale).
  • No built-in authentication. The HTTP/WebSocket API is not authentication-protected on its own. Do not expose it directly to the public internet.
  • Session tokens. Internal agent sessions are addressed by bearer-style tokens in the URL path. Treat daemon logs and request logs as sensitive.
  • Autonomous git/GitHub actions. Agents create branches and open pull requests using your configured gh/git credentials. main is never pushed to autonomously, but review the guardrails before granting credentials.
  • Secrets. Provide credentials via environment variables / .env (gitignored). Never commit secrets; agents are instructed not to surface secrets in logs or comments, but you remain responsible for scoping the credentials you supply.

Scope

Issues in third-party dependencies should be reported upstream, though we welcome a heads-up so we can bump the affected dependency.

There aren't any published security advisories