Bug-Bounty-Programm

Capgo ist sich der Sicherheit und Transparenz verpflichtet. Alle unsere code sind Open-Source und wir laden Sicherheitsforscher ein, uns bei der Identifizierung von Sicherheitslücken in unserem Codebase zu helfen.

Offene Quellcode Code

Jeder Repository in der Capgo Organisation ist Open-Source. Sie können unsere code überprüfen, auditen und zu ihnen beitragen.

GitHub Organisation: github.com/Cap-go

Anforderungen für gültige Berichte

Um für das Bug Bounty-Programm in Frage zu kommen, muss Ihr Bericht alle folgenden Anforderungen erfüllen:

• Sie müssen die genaue Datei und Zeilennummer in unserem GitHub-Repository angeben, an der die Schwachstelle existiert
• Ihr Bericht muss über GitHub Security Advisory auf dem relevanten Repository eingereicht werden
• Sie müssen eine klare Beschreibung der Schwachstelle und ihres potenziellen Auswirkungen bereitstellen
• Sie müssen reproduzierbare Schritte bereitstellen, um das Problem zu demonstrieren

Antwortzeit und Respekt

Wir sind freundlich und zahlen für gültige Berichte, aber wir können nicht mit Menschen zusammenarbeiten, die unser Zeit nicht respektieren. Bitte halten Sie die Kommunikation ruhig und folgen Sie diesem Programm.

• Wir beantworten Sicherheitsberichte und -brüche innerhalb von 24-72 Stunden.
• Spammen Sie uns nicht. Mehr als drei E-Mails an einem Tag gilt als Spam und wird blockiert.
• Wir zahlen nicht für Berichte, die diese Regeln ignorieren oder als Spam gelten.
• Nur Berichte, die diesem Bug Bounty Programm folgen, werden akzeptiert; alles andere kann blockiert werden.
• Bitten Sie nicht nach Status-Updates wie "haben Sie das überprüft?" oder ähnliche Fragen. Sobald wir bestätigen, dass wir Ihren Bericht erhalten haben, ist das genug. Danach ist noch viel Arbeit zu leisten, und die Erstellung eines Pull-Requests kann mehrere Tage dauern.

Wie man einen Bericht einreicht

1. Navigieren Sie zum relevanten Repository auf GitHub
2. Klicken Sie auf die "Sicherheit" Registerkarte
3. Klicken Sie auf "Melden Sie eine Sicherheitslücke" um eine neue Sicherheitsanzeige zu erstellen
4. Inkludieren Sie den genauen Dateipfad und Zeilennummer(n), an dem die Sicherheitslücke existiert
5. Bereitstellen Sie detaillierte Schritte, um das Problem nachzubilden und erklären Sie den Sicherheitsimpact

Außerhalb des Geltungsbereichs

• Berichte ohne genaue code Zeilenbezeichnungen in GitHub
• Berichte, die nicht über GitHub Sicherheitsanzeige eingereicht wurden
• Theoretische Sicherheitslücken ohne Nachweis eines Proof of Concept
• Fehler in dritter Partei-Plattformen, Abhängigkeiten oder Diensten, die Capgo direkt nicht beheben kann (melden Sie diese beispielsweise an Supabase).
• Soziale Ingenieurskunst oder Phishing-Versuche
• Dienstunterbrechungsangriffe

Supabase und Drittanbieterdienste

If der Grundursache ist ein Supabase-Plattform- oder -Dienstfehler, melden Sie ihn bei Supabase, nicht Capgo. Wenn die anfällige Logik, SQL, RPC, RLS-Politik, Edge-Funktion oder Konfiguration von Capgo erstellt oder gewählt wurde und wir sie in unserem Projekt beheben können, ist sie im Umfang, selbst wenn Supabase den Endpunkt bereitstellt. Für Befunde über Supabase-Verhaltensweisen selbst, einschließlich einer reproduzierbaren Anwendung und der genauen Supabase-Einstellung oder Konfigurationsänderung, die sie in einem Projekt konfiguriert wie unser verhindert.

Beispiele

Known Supabase Auth Limitations (Already Reported)

Einige Ergebnisse werden wiederholt gemeldet und werden durch Supabase Auth-Standardwerte oder Plattformverhalten verursacht und nicht durch Capgo code. Wir überprüfen diese nur, wenn sie in einem gemeinsamen Supabase-Demo-Projekt wie unserem konfiguriert werden können und wenn der Fix ein Supabase-Seitig- Konfigurationsänderung ist, die keine Änderung der Capgo Sicherheitsregeln erfordert. Wenn der Fix eine Änderung der Capgo-besitzenen SQL, RPCs, RLS-Politiken, Funktionen oder Anwendungslogik erfordert, melden Sie es uns, da dies im Umfang liegt.

• Bereitstellen Sie einen wiederholbaren Fall und identifizieren Sie den genauen Fix: entweder die Supabase-Einstellung/Konfigurationsänderung, die ein Supabase-Verhaltensproblem behebt, oder die Capgo-besitzene code/Konfigurationsobjekt, das geändert werden muss.
• Das E-Mail-Verifizierungsverhalten ist so zu erwarten, dass es Ihren Supabase-Auth-Projekt-Einstellungen folgt (z. B. ob die E-Mail-Bestätigung deaktiviert ist und die capture-basierte Auth verwendet wird).
• Die Passwortsynchronisierungs- und Konto-Wiederherstellungsflüsse erfordern nicht immer die Eingabe des alten Passworts oder die erneute Verifizierung, wenn Supabase Auth so konfiguriert ist.
• Wenn das Problem in dieser Liste ist, aber Sie können in dem bereitgestellten Projekt oder in einem konkreten Capgo-besitzenen Sicherheitsfehler einen konkreten Supabase-Seitigen Fix zeigen, können wir es im Umfang berücksichtigen.

Für Fragen zu unserem Bug Bounty-Programm wenden Sie sich bitte über unsere GitHub-Sicherheitsberichte.