Programme de récompense pour les failles de sécurité

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

Code source Code

Tous les dépôtoirs de l'organisation Capgo sont de code source ouvert. Vous pouvez examiner, auditer et contribuer à nos code.

Organisation GitHub : github.com/Cap-go

Exigences pour les Rapports Valides

Pour être éligible au programme de Bug Bounty, votre rapport doit répondre à TOUTES les exigences suivantes :

• Vous devez identifier l'emplacement exact du fichier et de la ligne dans notre GitHub répertoire où la vulnérabilité existe
• Votre rapport doit être soumis via GitHub Advisory de Sécurité sur le répertoire 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 amicaux 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.

• We traitons les rapports de sécurité et les failles dans 24-72 heures.
• Ne nous envoyez pas du spam. Plus de trois emails par jour est considéré comme du spam et sera bloqué.
• On ne paie 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é.
• Ne demandez pas d'informations 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 avis de sécurité
4. Incluez l'emplacement de fichier et le numéro de ligne exact où la vulnérabilité se trouve
5. Fournit des étapes détaillées pour reproduire le problème et expliquez l'impact de sécurité

Hors champ

• Les rapports sans références de ligne exactes code dans GitHub
• Les rapports ne soumis pas par le biais de GitHub de la sécurité de l'avertissement
• Les vulnérabilités théoriques sans preuve de concept
• Les bogues dans les plateformes, les dépendances ou les services tiers que Capgo ne peut pas fixer directement (signalez-les en amont, par exemple vers Supabase).
• Les tentatives de manipulation ou de phishing
• Les attaques de service en rejet
• Les rapports de SSRF ou de spoofing DNS contre les webhooks ou la prévisualisation du site Web. Ces fonctionnalités exécutent une infrastructure sans serveur et ne peuvent pas être utilisées pour atteindre l'infrastructure privée Capgo , donc elles ne sont pas exploitable dans notre environnement.

Supabase et Services tiers

Si la cause racine est un bogue de la plateforme ou du 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 lorsque Supabase exécute le point de terminaison. Pour les constats sur le comportement de Supabase lui-même, incluez un cas réplicable et la configuration Supabase ou le changement de paramètre exact qui l'empêche dans un projet configuré comme le nôtre.

Exemples

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

Certains problèmes sont signalés à plusieurs reprises et sont causés par les paramètres Auth Supabase par défaut ou le comportement de la plateforme plutôt que par Capgo code. Nous revoyons ces problèmes uniquement lorsque nous pouvons les reproduire dans un projet de démonstration Supabase partagé configuré comme le nôtre et lorsque la correction nécessite un changement de configuration Supabase qui ne nécessite pas de modification des règles de sécurité Capgo. Si la correction nécessite un changement de SQL, RPC, de politiques RLS, de fonctions ou de logique d'application Capgo-contrôlée, signalez-le-nous car cela est dans notre champ d'application.

• Fournissez un cas réprouducible et identifiez la correction exacte : soit le changement de configuration Supabase qui résout un problème de comportement Supabase, soit l'objet Capgo-contrôlée code/config qui doit changer
• Le comportement de vérification par e-mail est attendu pour suivre les paramètres de 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)
• Mises à jour de mot de passe et flux de récupération de compte ne nécessitent pas toujours la saisie ou la vérification de l'ancien mot de passe si Supabase Auth est configuré de cette manière.
• Si le problème est dans cette liste mais que vous pouvez afficher une solution concrète de Supabase pour ce projet ou un défaut de sécurité Capgo-propriétaire, nous pouvons le considérer dans le champ.

Pour des questions sur notre programme de Bug Bounty, veuillez nous contacter à travers nos GitHub Avis de Sécurité.