Programme de rançon de bugs

Capgo s'engage en faveur de la sécurité et de 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 codebase.

Source Ouverte Code

Tout le dépôt de l'organisation Capgo est source ouverte. Vous pouvez examiner, auditer et contribuer à nos code.

Organisation GitHub : github.com/Cap-go

Exigences pour les Rapports Valides

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

• Vous devez identifier l'exacte fichier et le numéro de ligne dans notre GitHub dépôt où la vulnérabilité existe
• Votre rapport doit être soumis via GitHub Security Advisory 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 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.

• Nous répondons aux rapports de sécurité et aux breaches dans un délai de 24 à 72 heures.
• N'envoyez pas de spam. Plus de trois emails par jour est considéré comme du spam et sera bloqué.
• Nous n'acceptons pas les rapports qui ignorent ces règles ou sont des spams.
• 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 confirmons avoir 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. Naviguez vers le référentiel 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. Includez l'exacte chemin de fichier et le numéro de ligne(s) où l'existence de la vulnérabilité est détectée
5. Fournissez 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 Security Advisory
• Les vulnérabilités théoriques sans preuve de concept
• Les bugs 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 phishing ou de manipulation sociale
• Les attaques de service en panne
• Les rapports de SSRF ou de spoofing DNS contre les webhooks ou la prévisualisation du site web. Ces fonctionnalités exécutent des infrastructures 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.
• La configuration de l'application code ou du projet détenue par l'utilisateur, que Capgo ne possède, n'expédie pas, ni contrôle, y compris les fichiers tels que capacitor.config.ts, config.capacitor.ts, le code source de l'application code, et les paramètres spécifiques à l'environnement.
• L'accès aux fichiers de bundle Capgo ou la preuve que les fichiers de bundle peuvent être téléchargés. Les fichiers de bundle sont des actifs web publics, les utilisateurs sont informés de cela, et l'accès à eux n'est pas considéré comme une violation de données.

Supabase et Services tiers

Si la cause racine est un bug ou un problème de service de la plateforme 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 sert le point de terminaison. Pour les constats sur le comportement de Supabase lui-même, incluez un cas réprouvable et le paramètre ou la modification de configuration Supabase exacte qui l'empêche dans un projet configuré comme le nôtre.

Exemples

Limitations de l'authentification Supabase (Déjà signalées)

Certains résultats sont signalés à plusieurs reprises et sont causés par les paramètres par défaut de Supabase Auth ou le comportement de la plateforme plutôt que Capgo code. Nous examinons ces cas 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 une modification de la configuration de Supabase qui ne nécessite pas de changement des Capgo règles de sécurité. Si la correction nécessite de modifier les Capgo-propriétaires SQL, RPC, politiques RLS, fonctions ou logique d'application, signalez-le-nous car cela est dans le champ.

• Fournissons un cas réprouducible et identifiez la correction exacte : soit la modification de la configuration de Supabase qui résout un problème de comportement de Supabase, soit l'objet Capgo-propriété code/config qui doit changer.
• Le comportement de vérification de l'adresse e-mail est attendu pour suivre les paramètres de projet d'authentification de Supabase (par exemple, si la confirmation de l'adresse e-mail est désactivée et l'authentification basée sur la capture est utilisée).
• Même si les flux d'actualisation de mot de passe et 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 montrer une correction concrète de Supabase dans le projet fourni ou un défaut de sécurité Capgo-propriété, nous pouvons le considérer dans le champ.

Pour les questions concernant notre programme de Bug Bounty, veuillez contacterz-nous à travers nos GitHub Avis de sécurité.