Security

Vulnerability reporting, what Mira does to keep your code safe, and the production hardening checklist.

Mira is self-hosted only. There is no Mira-managed cloud service. Your code never touches a server we control.

Reporting a vulnerability

We value the security community's role in keeping Mira safe.

File a private vulnerability report on GitHub: Report a vulnerability.
Or email support@miracode.ai.
Include steps to reproduce and any relevant context (affected versions, suggested mitigations).

We commit to:

Acknowledging your report within 3 business days.
Providing a status update within 7 business days.
Crediting you in the advisory and CHANGELOG (unless you prefer to remain anonymous).

We're a small open-source project and don't currently offer a paid bug bounty, but we credit every reporter (as noted above) and deeply appreciate responsible disclosure regardless.

Vulnerability categories

Priority	Category	Examples
P0	Supply chain	Compromise of our CI/CD that points the PyPI package or Docker images to tampered artifacts.
P1	Unauthenticated access	Bypassing webhook signature verification, reading dashboard data without a valid session.
P2	Authenticated malicious actions	Privilege escalation, prompt-injection that leaks indexed code outside the bot's intended responses.

Known non-issues

Misconfigurations on setup are explicitly out of scope. For example, not setting MIRA_WEBHOOK_SECRET, leaving ADMIN_PASSWORD at the default, or exposing the dashboard publicly without auth.
Vulnerabilities in third-party dependencies that don't affect Mira's actual usage. Please report those upstream.
Issues requiring physical access to the host running Mira.

Self-hosted posture

When you self-host Mira, the following holds by design:

No data or telemetry leaves your infrastructure. Nothing phones home, and there's no usage tracking or analytics service.
Code never touches a Mira-controlled server. Your code goes from your repo, through the LLM API key you provided, and back to your Mira instance. We're not in the path.
Indexes are stored locally, in your SQLite file or your Postgres database. There is no central index store.
Webhook signatures are verified with HMAC-SHA256 against MIRA_WEBHOOK_SECRET, and invalid signatures are rejected at the edge.
GitHub App tokens are cached in-process only, with a 55-minute TTL, and never written to disk. Tokens for installations you've removed expire automatically.
No license keys and no paywalls. Mira is fully open source under Apache 2.0.

Hardening checklist

Before pointing real PRs at a Mira deployment, work through this list.

MIRA_WEBHOOK_SECRET set to a long random value (32+ bytes). Without this, anyone who finds your webhook URL can forge events.
```
openssl rand -hex 32
```
ADMIN_PASSWORD changed from the default admin. Without this, your dashboard is open if it's network-reachable.
TLS in front of Mira. The image does not terminate TLS. See TLS examples for Caddy, nginx + Let's Encrypt, and Cloudflare Tunnel configs, or use a PaaS that handles TLS for you (Railway, Fly, Render).
Restrict ingress to /github/webhook to GitHub's published webhook IPs, or front the service with a reverse proxy that does. The rest of the service is auth-gated, but reducing attack surface is cheap.
Postgres TLS. If DATABASE_URL=postgres://…, append ?sslmode=require.
Secrets in a secret manager. Store MIRA_GITHUB_PRIVATE_KEY, LLM API keys, and DATABASE_URL in your platform's secret manager (Fly secrets, Railway variables, Render env groups, AWS Secrets Manager, Doppler, …). Never commit them.
Pin the image version. Use ghcr.io/miracodeai/mira:vX.Y.Z, not :latest, and update on a known cadence after release notes.

Supply chain hardening (project-side)

We treat compromise of our own release pipeline as a P0. The protections below are what the Mira project maintains on this repository:

Hardware 2FA (FIDO2) required on every account with write access. SMS / TOTP-only accounts are not allowed; both can be phished.
Branch protection on main: PR required, ≥1 review, status checks must pass, no force-push, no deletion.
Default-deny GitHub Actions tokens. Every workflow declares permissions: contents: read at the top and only widens per-job where actually needed. A malicious dependency in CI can't push commits.
Outside-collaborator workflow approval. PRs from non-collaborators require a maintainer to click "Approve and run" before any workflow executes, so secrets stay unreachable until then.
Eval secrets gated by environment approval. OPENROUTER_API_KEY lives in the production GitHub environment with required reviewers, so even an authorised workflow run can't reach the key without explicit approval.
Dependabot enabled for github-actions, pip, and npm, with weekly pinned-SHA bump PRs.
Signed release tags (git tag -s v0.1.0). An attacker who steals a session can't push a fake release tag without the signing key.
Trusted Publishers for any future PyPI publication: no long-lived API token to steal, OIDC-bound to this repo.

Container signing via cosign (sigstore keyless) on every Docker image release. Verify before deploying:

cosign verify ghcr.io/miracodeai/mira:vX.Y.Z \
  --certificate-identity-regexp 'https://github.com/miracodeai/mira/' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

If you spot a hardening gap on either side, please report it via the channels at the top of this page.

For security inquiries, please contact us at support@miracode.ai.