Current product boundary
- Gitbeep requests read access to the GitHub repositories a customer selects. The current GitHub App does not request repository write access.
- The assessment pipeline uses pull-request metadata, the description, changed-file paths and statuses, and addition/deletion counts. It does not persist source-file contents or full diff patches.
- Beep Rules match pull-request events, minimum impact, repositories, and path patterns. They deliver cards to Slack channels explicitly selected by a workspace administrator.
- The current Slack product is outbound-only. It does not ingest Slack message history, acknowledgements, reactions, or thread replies.
- Pull-request assessment remains a transparent deterministic rules engine. The separate PR-risk research tool runs only after a paid workspace owner or administrator deliberately submits a question; it sends that question and bounded excerpts from Gitbeep's reviewed PR-risk research corpus to Cloudflare AI Search and Workers AI, labels the result as AI-generated and advisory, and cannot change a risk rating or trigger a Slack message.
Technical safeguards
- Webhook authenticity: GitHub payloads, Slack requests, and Stripe events are verified with their provider signatures before processing. Delivery identifiers are recorded to reject duplicate webhook work.
- Integration secrets: provider credentials are stored as Cloudflare Worker secrets. Slack installation tokens are encrypted at the application layer with AES-256-GCM and a separately configured key before storage.
- OAuth protection: installation state is random, stored only as a hash, bound to a user and workspace, expires, and can be consumed once.
- Authentication: production sessions use secure cookies over HTTPS. Email sign-in codes are stored as hashes, expire after ten minutes, allow three attempts, and are rate-limited. Social accounts are not implicitly linked from matching email alone.
- Authorization: application queries scope customer records to a Gitbeep workspace, and administrative configuration changes require an owner or administrator role.
- AI research controls: the API requires an authenticated owner or administrator and current paid-plan access before reading RAG configuration or calling either provider. Production and staging use separate D1 databases and AI Search namespaces. Staging additionally enforces its configured daily credit allowance and one-request concurrency lease; paid production usage has no arbitrary Gitbeep daily application cap. Questions are not written verbatim to Gitbeep's application cache or error logs; inputs, retrieved context, and outputs remain bounded, and retrieval or generation failures are not automatically retried.
- Hosting and retention: the service runs on Cloudflare Workers with separate production and staging D1 databases and R2 archive buckets. Administrative responses are marked private and no-store. Terminal operational detail is written under a deterministic, fenced batch to R2 before D1 removal or compaction; R2 excludes raw code, diff patches, RAG questions and answers, authentication secrets, and billing-email content. Completed webhook rows retain a compact D1 replay guard. Manual AI answers remain eligible for the active cache for up to seven days and are then removed in bounded maintenance batches; Cloudflare D1 Time Travel can retain recoverable database history for the plan's separate recovery window.
- Browser protections: Gitbeep sets content-type, frame, referrer, and browser-permission security headers across the application.
Customer controls and shared responsibility
Workspace administrators choose which repositories Gitbeep can access, which events and paths match a rule, and which Slack channels receive cards. Customers should grant access only where needed, review integration permissions periodically, remove former members, protect their GitHub and Slack accounts, and verify critical assessment details in GitHub.
Uninstalling the GitHub or Slack App revokes future provider access. Disabling a Beep Rule stops its future deliveries. Data deletion can be requested at accounts@gitbeep.com.
Security program status
Gitbeep is an early-stage service. We do not currently claim SOC 2, ISO 27001, PCI DSS certification, a formal uptime SLA, or completion of an independent penetration test. Stripe, rather than Gitbeep, collects payment-card details. We review dependencies and application controls as the service develops and will update this page when independently verified assurances become available.
Report a vulnerability
Email accounts@gitbeep.com with the subject Security report. Include the affected URL, reproducible steps, impact, and a safe proof of concept. Do not access other customers' data, disrupt the service, use social engineering, or publicly disclose an issue before we have had a reasonable opportunity to investigate.
We will acknowledge reports as capacity permits, investigate in good faith, and notify affected parties when required by applicable law. Gitbeep does not currently operate a paid bug-bounty program.