Programme de rançon de bug

Capgo s'engage à la sécurité et à la transparence. Tous nos code sont sous licence open source, et nous accueillons les chercheurs en sécurité pour nous aider à identifier les vulnérabilités dans notre base de code.

Open Source Code

Chaque dépôt dans l'organisation Capgo est open source. Vous pouvez examiner, auditer et contribuer à nos code.

GitHub Organisation : github.com/Cap-go

Exigences pour les rapports valides

Pour être éligible au programme de Bug Bounty, votre rapport doit répondre à l'ensemble des exigences suivantes :

• Vous devez identifier le fichier et la ligne exacte de notre dépôt GitHub où la vulnérabilité existe
• Votre rapport doit être soumis via GitHub Advisory de sécurité sur le dépôt pertinent
• Vous devez inclure une description claire de la vulnérabilité et de son impact potentiel
• Vous devez fournir des étapes réproubables pour démontrer le problème

Temps de réponse et respect

Nous sommes sympathiques et nous payons pour les rapports valides, mais nous ne pouvons pas travailler avec des personnes qui ne respectent pas notre temps. Veuillez garder la communication calme et suivre ce programme.

• Nous répondons aux rapports de sécurité et aux failles dans les 24-72 heures.
• N'envoyez pas de spam. Plus de trois emails par jour est considéré comme du spam et sera bloqué.
• Nous ne payons pas les rapports qui ignorent ces règles ou sont du spam.
• Seuls les rapports pertinents qui suivent ce programme de bug bounty sont acceptés; tout autre peut être bloqué.
• N'interrogez pas sur les mises à jour de statut comme "avez-vous vérifié?" ou des questions similaires. Une fois que nous avons confirmé que nous avons reçu votre rapport, cela suffit. Après cela, il y a encore beaucoup de travail à faire, et la préparation d'une demande de tirage peut prendre plusieurs jours.

Comment signaler un problème

1. Accédez au répertoire pertinent sur GitHub
2. Cliquez sur l'onglet "Sécurité"
3. Cliquez sur "Signaler une vulnérabilité" pour créer un nouveau conseil de sécurité
4. Incluez le chemin d'accès exact et le numéro de ligne(s) où la vulnérabilité existe
5. Fournissez des étapes détaillées pour reproduire l'erreur et expliquez l'impact de sécurité

Hors de portée

• Rapports sans références de ligne exactes code dans GitHub
• Rapports non soumis via GitHub Advisory de sécurité
• Vulnérabilités théoriques sans preuve de concept
• Bugs dans les plateformes, les dépendances ou les services tiers que Capgo ne peut pas fixer directement (signalez-les vers l'amont, par exemple vers Supabase)
• Essais de phishing ou de social engineering
• Attaques de saturation de service

Supabase et Services tiers

Si la cause racine est un bug de la plateforme ou d'un service Supabase, signalez-le à Supabase et non à Capgo. Si la logique vulnérable, SQL, RPC, politique RLS, fonction Edge ou la configuration a été créée ou choisie par Capgo et que nous pouvons la corriger dans notre projet, elle est dans le champ même si Supabase sert l'endpoint. Pour les constats sur le comportement de Supabase lui-même, incluez un cas réplicable et la modification de configuration Supabase ou de paramètre exacte qui l'empêche dans un projet configuré comme le nôtre.

Exemples

Limitations Auth Supabase connues (Déjà signalées)

Some findings are repeatedly reported and are caused by Supabase Auth defaults or platform behavior rather than Capgo code. We review these only when they can be reproduced in a shared Supabase demo project configured like ours and when the fix is a Supabase-side configuration change that does not require changing Capgo security rules. If the fix requires changing Capgo-owned SQL, RPCs, RLS policies, functions, or app logic, report it to us because that is in scope.

• Fournir un cas reproducible et identifier la correction exacte : soit la modification de la configuration Supabase qui résout un problème de comportement Supabase, soit l'objet Capgo-contrôlé/ code qui doit changer
• Le comportement de vérification par e-mail est attendu pour suivre les paramètres du projet Auth Supabase (par exemple, si la confirmation par e-mail est désactivée et l'authentification basée sur la capture est utilisée)
• Les flux de mise à jour de mot de passe et de récupération de compte ne nécessitent peut-être pas toujours la saisie ou la vérification de l'ancien mot de passe si Supabase Auth est configuré de cette façon.
• Si le problème est dans cette liste mais que vous pouvez montrer une correction concrète du côté Supabase dans le projet fourni ou un défaut de sécurité Capgo-propriétaire, nous pouvons le considérer dans le champ.

Pour des questions relatives à notre programme Bug Bounty, veuillez contacter notre GitHub Security Advisories.