Trust & Safety
Security & Privacy
Ribix is designed around a minimal-data principle: we read what we need to detect bugs and generate fixes, store what we need to power the product, and never retain source code in a database.
What Ribix reads
During a proactive agent run or reactive enrichment, Ribix accesses the following:
- Repository contents (read-only, transient). Ribix reads your source code via the GitHub API to compute git blame, identify candidate files, analyze CODEOWNERS, and generate fix diffs. This access is read-only and ephemeral - code is processed in memory and is not written to a persistent database.
- GitHub Issues. Issue titles, bodies, and metadata are read to produce enrichment comments. Issue content is stored as part of the enrichment record.
- Staging environment responses. The browser agent makes real HTTP requests to your staging URL and reads the responses (HTML, JSON, network errors). These are processed to identify bugs and are not stored beyond what is needed for a specific finding.
- Git history and blame. Ribix reads commit metadata (author, message, timestamp, files changed) to identify suspect changes and code owners. Commit diffs relevant to a finding are included in the finding record.
What is stored
Ribix stores the minimum data needed to power the product across sessions.
| Data item | Stored? | Notes |
|---|---|---|
| Workspace & account records | ✓ Stored | Name, email, GitHub identity, workspace settings, and billing state. |
| Finding records | ✓ Stored | Severity, description, failing test, proposed diff, status, and approval metadata. |
| Enrichment records | ✓ Stored | Enrichment content, GitHub Issue reference, severity, and routing result. |
| Git blame & commit metadata | ✓ Stored | Suspect commit list and blame attribution used for enrichment and owner routing. |
| Issue content | ✓ Stored | Issue title and body for connected repositories (used for semantic search and enrichment). |
| Embeddings | ✓ Stored | Vector embeddings of issues and findings for related-issue retrieval. |
| Source code (full files) | ✗ Not stored | Ribix reads source code transiently for analysis but does not write it to a database. |
| Staging credentials (tokens/cookies) | ✓ Stored | Encrypted with AES-256-GCM. The plaintext value is never written to logs or shown in the dashboard after initial setup. |
Encryption
In transit
- All traffic between the Ribix CLI, dashboard, and backend uses TLS 1.2+.
- GitHub App webhook payloads are validated via HMAC-SHA256 before processing.
- Staging environment requests are made over HTTPS - plain HTTP endpoints are rejected.
At rest
- Staging credentials (bearer tokens, session cookies) are encrypted with AES-256-GCM before storage.
- The encryption key is derived from a workspace-specific secret stored separately from the data.
- Database storage uses provider-managed encryption at rest.
In use
- Source code is processed in memory during analysis - not written to disk or a database.
- GitHub installation tokens are short-lived and generated per-request.
- AI model calls include only the minimal context needed for the analysis (issue text + relevant code snippets).
Data deletion
You can request deletion of your workspace data at any time. Ribix processes deletion requests through two paths:
- Self-serve (repository disconnect). Toggling off a repository in the dashboard stops new enrichments and queues cleanup of the associated enrichment records and clone-cache data through the normal retention lifecycle.
- Account & workspace deletion. Email privacy@ribix.dev with your account or workspace identifier. All associated records (findings, enrichments, embeddings, workspace settings, and billing state) are deleted within 30 days. A full self-serve account closure flow is on the product roadmap.
Data retention
Workspace data is retained for the life of your account and deleted within 90 days of account closure. See our Privacy Policy for full retention schedules and legal basis for processing.
AI model usage
Ribix uses AI models to draft enrichment comments and generate fix diffs. Details on how your data is used in model calls:
- What is sent to models. Issue text, relevant code snippets (not full files), git blame fragments, and the Ribix system prompt. We do not send your full repository to any model API.
- Training. We use aggregated, anonymized quality signals to improve global model accuracy. We do not fine-tune models on individual customer data without explicit written agreement.
- Model providers. Ribix uses one or more third-party AI providers. Data sent to these providers is covered by their respective data processing terms. Contact us if you need specifics for compliance review.
GitHub App security
- The Ribix GitHub App requests the minimum permissions needed for product behavior. See Integrations for the full permission list.
- GitHub installation tokens are short-lived and generated on demand per API call - they are never stored.
- Webhook event payloads are verified with HMAC-SHA256 before processing begins. Unverified payloads are rejected.
- Ribix never touches production environments. The agent only runs against the staging URL you configure.
Compliance & trust material
For full legal and trust documentation:
- Security overview - detailed baseline controls, infrastructure security, and incident response process.
- Privacy Policy - full data processing terms, retention schedules, and legal basis.
- Terms of Service - product usage terms.
For enterprise compliance questions (SOC 2, Data Processing Agreements, custom retention schedules) contact security@ribix.dev.