This text is a working draft. Some details are still to be filled in, and the whole document must be reviewed by a qualified lawyer before it carries any weight. It is not a contractual commitment as it stands.
Security & Vulnerability Disclosure
01Important notice
This document is a working draft. It must be reviewed and validated by a qualified legal professional and the security team before publication.
02Our security commitment
Security is foundational to RingSync's product design. The service is built around a no-contact-storage architecture: directory contact records pass through our proxy in memory and are written directly to employees' devices — they are never persisted in the RingSync database.
OAuth tokens (Microsoft application credentials) are encrypted at rest using Supabase Vault (AES-256 envelope encryption). They are decrypted in memory only for the duration of each proxied API call.
All data in transit is protected by TLS 1.2 or higher. Mobile session tokens are stored in the device's secure enclave via Expo SecureStore (iOS Keychain / Android Keystore).
RingSync's primary infrastructure is hosted in the European Union. {{À VALIDER : préciser la région et le fournisseur d'infrastructure}}.
{{À VALIDER : SOC 2 Type II — audit en cours, certification attendue pour {{À VALIDER : date}}}}.
03Architecture security highlights
- No direct database access from client-side code: all database operations go through server-side API routes using service-role credentials.
- Row-Level Security (RLS) on all Supabase tables: each administrator can only read data belonging to their own organisation.
- Application-level credentials for Microsoft Graph: RingSync uses the client_credentials OAuth flow server-side; employees' personal Microsoft tokens are not stored.
- Selective wipe: when a user is deprovisioned, only the contacts tagged for that specific directory are removed from the device — other directories' contacts are untouched.
- Session revocation: mobile JWTs can be individually revoked via the session_revoked_at flag, effective immediately on the next API call.
04Responsible disclosure policy
RingSync welcomes reports of security vulnerabilities from the security research community. We ask that you:
- Report the vulnerability to us before public disclosure, giving us reasonable time to investigate and remediate.
- Not exploit the vulnerability beyond what is necessary to demonstrate its existence.
- Not access, modify or delete data belonging to other customers.
- Not perform denial-of-service tests or automated scanning without prior written permission.
To submit a report, use the Security & vulnerability disclosure channel at /contact. Please do not send vulnerability reports to the general support address.
We commit to: acknowledging receipt of your report within 24 hours; providing an initial triage assessment within 72 hours; keeping you informed of our progress; crediting you in our security acknowledgements (unless you prefer anonymity).
We do not currently operate a paid bug bounty programme. {{À VALIDER : si un programme HackerOne / Bugcrowd est envisagé}}.
PGP key for encrypted submission: {{À VALIDER : empreinte de clé PGP ou retrait de cette mention si non applicable}}.
05Incident response
In the event of a confirmed security incident affecting customer data, RingSync will: contain the incident; notify affected customers within {{À VALIDER : délai — 72 heures recommandé par le RGPD pour notification à l'autorité}} of becoming aware of the breach; notify the CNIL (or relevant supervisory authority) where required by Art. 33 GDPR.
{{À VALIDER : politique interne de gestion des incidents — AIPD, registre des violations}}.