Programme de récompense pour les 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.

Code source Code

Tout repository de l'organisation Capgo est sous licence 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 Bug Bounty, votre rapport doit répondre à TOUTES les exigences suivantes :

• Vous devez identifier l'exacte ligne et le 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épéductibles pour démontrer l'incident

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 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 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. Navigatez vers le référentiel pertinent sur GitHub
2. Appuyez sur l'onglet « Sécurité »
3. Appuyez sur « Signaler une vulnérabilité » pour créer un nouveau conseil de sécurité
4. Incluez l'emplacement de fichier et le numéro de ligne exact où la vulnérabilité existe
5. __CAPGO_KEEP_0__ est une petite entreprise auto-suffisante, donc nos montants de récompense sont inférieurs à ceux des grands programmes d'entreprise. Les rapports sans chemin d'exploitation clair sont payés jusqu'à 30 $ maximum. Les exploits avec un impact réel et réprouvable sur __CAPGO_KEEP_1__ sont payés jusqu'à 300 $ maximum. Nous acceptons et examinons les rapports de sécurité pour les plugins __CAPGO_KEEP_2__ mais les récompenses payées pour les plugins __CAPGO_KEEP_3__ sont limitées à @__CAPGO_KEEP_4__/__CAPGO_KEEP_5__-mises à jour. Les autres plugins __CAPGO_KEEP_6__ sont gratuits et ne font pas partie de notre offre de produit payante, donc les rapports pour eux sont examinés mais non payés. Les paiements sont émis uniquement après que nous ayons identifié le problème, publié la correction et que vous ayez vérifié post-publication que la correction fonctionne pour vous. L'ouverture ou la liaison d'une demande de tirage ne qualifie pas pour le paiement. Ce processus prend généralement quelques jours à quelques semaines en fonction de la gravité et du rythme de publication. Veuillez ne pas envoyer de messages comme « pour obtenir des paiements » ; les paiements ne se produisent qu'une fois la mise en ligne est terminée et que vous avez testé et validé la correction.

Sortants de portée

• Les rapports sans références de ligne exactes code dans GitHub
• Les rapports non soumis via le conseil de sécurité GitHub
• Les vulnérabilités théoriques sans preuve de concept
• Les bogues dans les plateformes tiers, les dépendances ou les services que Capgo ne peut pas fixer directement (signalez-les en amont, par exemple à Supabase).
• Les tentatives d'ingénierie sociale ou de phishing
• Les attaques de refus de service
• Les rapports de SSRF ou de DNS spoofing contre les webhooks ou la prévisualisation du site. Ces fonctionnalités fonctionnent sur une infrastructure sans serveur et ne peuvent pas être utilisées pour atteindre l'infrastructure privée Capgo , ils ne sont donc pas exploitables dans notre environnement.
• La configuration de l'application code ou du projet que Capgo ne possède pas, n'expédie pas, ou ne contrôle pas, y compris les fichiers tels que capacitor.config.ts, config.capacitor.ts, les sources de l'application code et les paramètres spécifiques à l'environnement.
• Accès aux fichiers du bundle Capgo ou la preuve que les fichiers du bundle peuvent être téléchargés. Les fichiers du 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.
• Unauthenticated Capgo plugin/API endpoints that are intentionally public by design — including channel_self set and update/stats endpoints that do not require an API key — are not vulnerabilities. Do not report them as such.
• Le labelleur de l'uploader ou de l'interface utilisateur qui étiquette incorrectement l'encryption pour les bundles servis via external_url n'est pas une vulnérabilité Capgo (l'encryption des bundles externes est hors du contrôle de Capgo ).

Supabase et Services tiers

Si la cause racine est un bug du plateau ou d'un service Supabase, signalez-l’à 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 le point de terminaison. Pour les trouvailles concernant le comportement Supabase lui-même, incluez un cas réplicable et le paramètre Supabase exact ou la modification de configuration qui l'empêche dans un projet configuré comme le nôtre.

Exemples

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

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

• Fournissez un cas de reproduction et identifiez la correction exacte : soit le paramètre/configuration Supabase qui résout un problème de comportement Supabase, soit l'objet Capgo-propriété code/config 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 si 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 vérification de l'ancien mot de passe si Supabase Auth est configuré de cette façon.
• Si l'incident est dans cette liste mais que vous pouvez montrer une correction concrète du côté Supabase dans le projet fourni ou une défense de sécurité Capgo-propriété, nous pouvons le considérer dans le champ.

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