Security

Report a vulnerability

If you believe you have found a security issue in GitMon — web app, API, browser extension, or infrastructure — please report it privately. Do not open a public GitHub issue or disclose the vulnerability publicly before we have had a chance to fix it.

Our commitments

• We will acknowledge your report within 3 business days.
• We will investigate and communicate a triage decision within 10 business days.
• We will not take legal action against researchers who act in good faith, report privately, and do not exploit the vulnerability beyond what is necessary to demonstrate it.
• We will credit you (with your permission) in the release notes of the fix.
• GitMon is an independent project. We do not operate a paid bug bounty yet. We can offer public credit, a thank-you, and (for high-impact reports) GitMon Plus lifetime access.

Scope

The following surfaces are in scope for responsible disclosure:

• Web app at gitmon.io
• Public API endpoints under /api/v1/*
• Browser extension (Chrome Web Store listing, once published)
• Authentication + OAuth flow
• Extension handoff + session management

Out of scope:

• Third-party services we depend on (Supabase, Vercel, Upstash, GitHub, Anthropic, OpenAI) — report those directly to the vendor.
• Social engineering, phishing, or physical attacks.
• Denial-of-service attacks against our infrastructure (please don't).
• Missing security headers with no demonstrable impact.
• Vulnerabilities in outdated browsers or unsupported platforms.

How we protect your data

• Authentication: GitHub OAuth via Supabase Auth. We never ask for or see your GitHub password.
• GitHub tokens: encrypted at rest with AES-256-GCM (envelope format v1:iv:tag:ct), decrypted only inside the server routes that need to call the GitHub API. Scoped to read:user,repo. We use the token exclusively to read event metadata (commit counts, PR timestamps, issue types). We never read source code, file contents, diffs, repository settings, secrets, or collaborator lists, and we never perform write operations of any kind. See our Privacy Policy for a full breakdown of why the repo scope is required and which other developer tools request the same permission.
• Row-level security: every database table enforces PostgreSQL RLS. A user can only read or write rows they own. Security-critical functions run with SECURITY DEFINER and perform their own ownership checks.
• Transport security: all traffic is HTTPS only, with HSTS enabled at the edge.
• Rate limiting: public endpoints are rate-limited per IP (Upstash Redis) to mitigate abuse.
• Extension sessions: 64-hex tokens with a 30-day rolling TTL, validated via an atomic SECURITY DEFINER SQL function. You can revoke any device from settings without affecting your web login.
• Secrets management: no secrets or API keys committed to the repository. Production secrets live in Vercel environment variables, scoped per environment.
• LLM API keys (yours): if you provide an Anthropic or OpenAI key for chat features, it is stored at rest in plaintext (not encrypted) and gated by row-level security so only you can read it. We chose plaintext because the key flows from your dashboard or extension straight to the LLM provider — we never proxy your chat content except for the CLI (see next bullet). You can remove it from Settings at any time, and rotating the key on the provider side immediately invalidates the stored copy.
• CLI chat exception: the gitmon-cli binary cannot elegantly dispatch multi-provider HTTPS from a POSIX shell, so the server proxies the LLM call on its behalf. During each CLI chat request (~1–3 seconds) your plaintext LLM key is held in server RAM alongside the outbound HTTPS call, then discarded. The key is never written to any log, Sentry event, or analytics payload — enforced by a test that greps the build output and a Sentry beforeSend scrubber that strips any property matching /llm.?api.?key|api_key|apikey/i. The web chat and browser extension still call the LLM directly from your device.
• CLI sessions: 64-hex bearer tokens with a 90-day rolling TTL, stored at rest as SHA-256 only (same protection as extension sessions). Locally the token lives at ~/.config/gitmon/token with mode 600. You can revoke any CLI device from Settings without affecting other sessions.
• Input validation: every API boundary validates input with Zod schemas before touching business logic.

Infrastructure

• Hosting: Vercel (web + API, edge functions)
• Database: Supabase (managed PostgreSQL)
• Cache + rate limiting: Upstash Redis
• Auth provider: Supabase Auth with GitHub OAuth
• LLM providers (opt-in, user-provided keys): Anthropic, OpenAI

Infrastructure-level security issues (Supabase, Vercel, Upstash) should be reported to those vendors directly.

Compliance alignment

GitMon is an independent project and is not yet formally certified under any security framework. Our practices are aligned with:

• GDPR Article 5(1)(c) and LGPD Article 6 — data minimization and necessity principles
• RFC 6749 §3.3 — OAuth scope least privilege (constrained by GitHub's scope granularity)
• ISO 27001 — access control, data classification, and incident response principles
• OWASP ASVS Level 2 — authentication, session management, input validation, and API security

Past incidents

No security incidents have been reported to date. We will publish post-mortems here for any future incidents that affect user data.

See also

• Privacy Policy — what we collect, how it is used, your rights
• Terms of Service — account rules, acceptable use, liability

Contact

Security and general inquiries: bruno@b2tech.io

GitMon is operated by Bruno Bracaioli, an independent developer based in Brazil.