If you discover a security vulnerability, please report it responsibly.

Do NOT open a public GitHub issue.

Use either channel below:

1. GitHub Private Vulnerability Reporting — strongly preferred. https://github.com/kensaurus/mushi-mushi/security/advisories/new Routes the report into a private advisory with built-in CVE issuance, patch coordination, and contributor-credit workflow.
2. Email — kensaurus@gmail.com, subject prefix [mushi-security]. PGP welcome but not required.

Include:

• Description of the vulnerability
• Steps to reproduce (smallest reproducer wins)
• Impact assessment (what an attacker gains)
• Suggested fix (if any)
• Whether you want public credit (and how to spell your name)

Good-faith security research on Mushi Mushi is welcome. If you stay within the rules below, we will not pursue legal action, will not ask your hosting provider to take you offline, and will publicly credit your work:

• Test only against your own self-hosted instance, the public demo at https://kensaur.us/mushi-mushi/admin/, or accounts you own.
• Do not access, exfiltrate, or modify data belonging to other users.
• Do not run automated scanning that affects availability for others (rate-limit your tooling, exclude /health).
• Disclose privately first (channels above); do not publish before the embargo above expires.
• Do not intentionally exploit a finding to escalate beyond proving it exists.

If a finding requires touching production data to confirm, stop and ask first — describe what you'd need to do and we'll spin up a sandbox.

Researchers who report a confirmed vulnerability are credited in the release notes for the patched version and added to docs/SECURITY_HALL_OF_FAME.md (with permission).

• All @mushi-mushi/* npm packages
• Supabase Edge Functions (server-side)
• Admin console application
• CLI tool

• Self-hosted deployments configured by the user
• Third-party integrations (Jira, Linear, PagerDuty)
• Vulnerabilities requiring physical access

• Never commit your API keys — use environment variables
• Rotate API keys regularly via the admin console
• Enable SSO for team projects (Enterprise tier)
• Review audit logs periodically for suspicious activity
• Verify SDK integrity with npm audit signatures after install
• Set Content-Security-Policy on any page embedding the Mushi widget; the widget itself ships with script-src 'self' and does not load remote scripts.

What we treat as in-scope attacker capabilities, and what we don't.

Implemented identically across @mushi-mushi/core, the iOS, Android, Flutter, and React Native SDKs. Defaults are below — every category can be toggled off, but secretTokens is on by default and we recommend keeping it that way.

The fields scrubbed are:

• description — primary free-text field of every bug report
• summary — short summary, in the same composer
• breadcrumbs[].message — auto-captured user-action trail (clicks, route changes, console messages)

Structured fields you set explicitly (metadata.userEmail, metadata.userId, etc.) are intentionally not scrubbed — those are opt-in attribution data, and silently rewriting them would break support workflows.

• Reports & telemetry — Supabase Postgres in the us-west-1 region.
• Session replays — Supabase Storage, same region. Lifecycle policy trims replays older than 30 days unless explicitly retained from the admin console.
• Inbound webhook bodies — only a SHA-256 hash + delivery_id of the body is persisted (webhook_audit_log). The full body is processed in memory and discarded.
• Outbound integrations (Slack, Jira, …) — Mushi is a sender only; the receiving system's retention applies.

We deliberately do not roll our own crypto. If you find an algorithm or library above that has been deprecated, please file a security advisory.

When you provision a new self-hosted Mushi instance:

• Set auth_leaked_password_protection = true in Supabase Auth (HaveIBeenPwned blocklist; flagged as auth_leaked_password_protection in the security advisor).
• Enable at least two MFA factors in Supabase Auth (auth_insufficient_mfa_options).
• Rotate the service-role key on day 1, then quarterly.
• Restrict Postgres direct connections to your CI / migration runners via Supabase network restrictions.
• Run pnpm dlx supabase advisors --project-ref <ref> after every migration; aim for zero ERROR-level findings.
• Configure a Supabase log drain to your SIEM if you are subject to SOC 2 / ISO 27001.
• Set CSP frame-ancestors on the host page if you embed the Mushi widget (the widget is iframe-friendly but does not enforce framing constraints itself).

Mushi Mushi is built and published with the controls below. Consumers can verify each control independently — the goal is to make tampering both difficult and detectable.

# 1. Check provenance attestation matches the public GitHub Actions run
npm view @mushi-mushi/core --json | jq '.signatures, .dist'

# 2. Inside your own project after install
npm audit signatures

# Expected: every @mushi-mushi/* package reports
#   "verified registry signature"
#   "verified attestation"

If npm audit signatures reports any @mushi-mushi/* package as unsigned or with an invalid attestation, stop the install and email kensaurus@gmail.com immediately — that's the symptom of either a registry compromise or a tampered tarball, and we want to know within hours, not days.

• Self-hosted deployments. Once the package is on your machine, the security of your node_modules, build pipeline, and runtime is your responsibility. The hardening above protects the path from source to registry; it cannot protect a tarball after it has been downloaded.
• Compromise of kensaurus@gmail.com. A trusted-publisher rule still lets the legitimate maintainer publish from any branch they push. If you find yourself with admin access to this repo, treat .github/workflows/release.yml as a tier-0 secret.
• First-party bugs. Provenance proves who built the tarball and when; it does not prove the code is bug-free. CodeQL + tests cover that surface, but no automation catches everything — please continue to report issues to the address above.