Programme de rançon de bug

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 codebase.

Source Ouvrée Code

Tous les dépôtoirs dans l'organisation Capgo sont 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'emplacement exact du fichier et du numéro de 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éproudables 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 intrusions 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 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épertoire pertinent sur GitHub
2. Appuyez sur l'onglet "Sécurité"
3. Cliquez sur "Signalez une vulnérabilité" pour créer un nouveau conseil de sécurité
4. Incluez l'emplacement de fichier exact et le numéro de ligne(s) où la vulnérabilité existe
5. Proposez des étapes détaillées pour reproduire l'incident et expliquez l'impact de sécurité

Hors de portée

• Les rapports sans références de ligne exactes code dans GitHub
• Les rapports non soumis via GitHub Conseil de sécurité
• 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 sociale ou de phishing
• Les attaques de refus de service
• Les rapports de SSRF ou de spoofing DNS contre les webhooks ou les prévisualisations de 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.
• Application ou projet de configuration code propriétaire de l'utilisateur ou qui Capgo ne possède pas, n'expédie pas, ou ne contrôle pas, y compris des fichiers comme capacitor.config.ts, config.capacitor.ts, source d'application code, et 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 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 reproductible et le changement de configuration Supabase exact ou de paramètre qui l'empêche dans un projet configuré comme le nôtre.

Exemples

Limitations de Supabase Auth connues (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 règles de sécurité Capgo. Si la correction nécessite une modification des règles de sécurité SQL, des RPC, des politiques RLS, des fonctions ou de la logique de l'application Capgo, signalez-le-nous car cela est dans le champ.

• Fournir un cas reproducible et identifier la correction exacte : soit la modification de la configuration de Supabase qui résout un problème de comportement de Supabase, soit l'objet de configuration Capgo-propriété code qui doit changer.
• Le comportement de vérification par e-mail est attendu pour suivre les paramètres du projet d'authentification 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 le problème est dans cette liste mais que vous pouvez montrer une correction concrète de Supabase côté 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 Security Advisories.