Programme de récompense pour les bogues

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

Source ouverte Code

Chaque dépôt dans l'organisation Capgo est de 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 de 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 répertoire GitHub où le vulnérabilité existe
• Votre rapport doit être soumis à travers 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.

• Nous répondons aux rapports de sécurité et aux breaches dans 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 pour les rapports qui ignorent ces règles ou sont du spam.
• Seuls les rapports en portée 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 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. Naviguez vers le 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 exacts où la vulnérabilité existe
5. Fournissez des étapes détaillées pour reproduire l'erreur et expliquez l'impact de sécurité

Hors champ

• Rapports sans références de ligne code exactes dans GitHub
• Rapports non soumis via le GitHub Security Advisory
• 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 corriger directement (signalez-les en amont, par exemple vers Supabase)
• Les tentatives d'ingénierie sociale ou de phishing
• Les attaques de service en rejet
• Les rapports de SSRF ou de spoofing DNS contre les webhooks ou les prévisualisations du site web. Ces fonctionnalités fonctionnent sur une infrastructure sans serveur et ne peuvent pas être utilisées pour atteindre l'infrastructure privée Capgo, elles ne sont donc pas exploitable dans notre environnement.
• La configuration de l'application ou du projet code propriété de l'utilisateur, qui Capgo ne possède pas, n'expédie pas, ni ne contrôle, y compris des 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 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 lorsque Supabase sert l'endpoint. Pour les constats sur le comportement de Supabase lui-même, incluez un cas réplicable et le paramètre Supabase exact ou la modification de la configuration qui l'empêche dans un projet configuré comme le nôtre.

Exemples

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

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

• Fournissez un cas reproducible et identifiez la correction exacte : soit la modification de la configuration de Supabase qui résout une question de comportement de Supabase, soit l'objet Capgo-détenue 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).
• Les flux de mise à jour de mot de passe et de récupération de compte ne nécessitent pas toujours la saisie ou la re-vérification du mot de passe ancien si Supabase Auth est configuré de cette manière.
• Si l'incident est dans cette liste mais vous pouvez afficher une solution concrète de Supabase dans le projet fourni ou un défaut de sécurité concrètement Capgo-propriétaire, nous pouvons le considérer dans le champ.

Pour les questions relatives à notre programme de Bug Bounty, veuillez nous contacter à travers nos GitHub Conseils de Sécurité.