Bug-Bounty-Programm

Capgo ist Sicherheit und Transparenz verpflichtet. Unser gesamter code ist Open Source, und wir freuen uns über Security Researcher, die uns helfen, Schwachstellen in unserer Codebasis zu finden.

Open-Source-Code

Jedes Repository in der Capgo-Organisation ist Open Source. Du kannst unseren code prüfen, auditieren und aktiv mitgestalten.

GitHub Organisation: github.com/Cap-go

Anforderungen an gültige Reports

Um für das Bug-Bounty-Programm infrage zu kommen, muss dein Report ALLE folgenden Anforderungen erfüllen:

• Du musst die exakte Datei und Zeilennummer in unserem GitHub Repository angeben, in der die Schwachstelle liegt.
• Dein Report muss über das GitHub Security Advisory im entsprechenden Repository eingereicht werden.
• Du musst eine klare Beschreibung der Schwachstelle und ihrer potenziellen Auswirkungen liefern.
• Du musst reproduzierbare Schritte bereitstellen, um das Problem aufzuzeigen.

Reaktionszeit und Respekt

Wir sind freundlich und zahlen für valide Reports, aber wir arbeiten nicht mit Leuten zusammen, die unsere Zeit nicht respektieren. Bitte kommuniziere sachlich und halte dich an dieses Programm.

• Wir reagieren auf Security Reports und Breaches innerhalb von 24–72 Stunden.
• Bitte spamme uns nicht zu. Mehr als drei E-Mails an einem einzigen Tag gelten als Spam und werden blockiert.
• Wir zahlen nichts für Reports, die diese Regeln ignorieren oder Spam sind.
• Nur In-Scope-Reports, die dieses Bug Bounty Programm einhalten, werden akzeptiert; alles andere kann blockiert werden.
• Bitte frage nicht nach Status-Updates wie „Hast du es schon geprüft?“ oder ähnlichen Fragen. Sobald wir den Erhalt deines Reports bestätigt haben, reicht das. Danach steht noch viel Arbeit an, und einen Pull Request vorzubereiten kann mehrere Tage dauern.

So meldest du einen Bug

1. Navigiere zum entsprechenden Repository auf GitHub
2. Klicke auf den Tab „Security“
3. Klicke auf „Report a vulnerability“, um ein neues Security Advisory zu erstellen
4. Gib den genauen Dateipfad und die Zeilennummer(n) an, in denen die Schwachstelle liegt
5. Beschreibe detailliert die Schritte zur Reproduktion und erkläre die Sicherheitsauswirkungen

Nicht im Scope

• Reports ohne exakte code Zeilenangaben in GitHub
• Reports, die nicht über GitHub Security Advisory eingereicht wurden
• Theoretische Schwachstellen ohne Proof of Concept
• Bugs in Drittanbieter-Plattformen, Dependencies oder Services, die Capgo nicht direkt fixen kann (melde diese upstream, z. B. an Supabase).
• Social Engineering oder Phishing-Versuche
• Denial-of-Service-Angriffe
• SSRF- oder DNS-Spoofing-Meldungen zu Webhooks oder Website-Previews. Diese Features laufen auf Serverless-Infrastruktur und können nicht genutzt werden, um private Capgo Infrastruktur zu erreichen; in unserer Umgebung sind sie daher nicht ausnutzbar.
• Vom Nutzer verwaltete code App- oder Projektkonfiguration, die Capgo nicht besitzt, ausliefert oder kontrolliert, einschließlich Dateien wie capacitor.config.ts, config.capacitor.ts, App-Source code und umgebungsspezifischen Einstellungen.
• Zugriff auf Capgo Bundle-Dateien oder der Nachweis, dass Bundle-Dateien heruntergeladen werden können. Bundle-Dateien sind öffentliche Web-Assets, Nutzer werden darüber informiert, und der Zugriff darauf gilt nicht als Datenleck.
• Nicht authentifizierte Capgo Plugin/API Endpoints, die absichtlich öffentlich sind – einschließlich channel_self set und Update/Stats-Endpoints, die keinen API Key erfordern – sind keine Schwachstellen. Bitte nicht als solche melden.
• Wenn Uploader oder UI die Verschlüsselung für Bundles, die über external_url ausgeliefert werden, falsch kennzeichnen, ist das keine Capgo Schwachstelle (die Verschlüsselung extern gehosteter Bundles liegt außerhalb der Kontrolle von Capgo).

Supabase und Drittanbieter-Services

Wenn die Ursache ein Bug in der Supabase-Plattform oder einem Service ist, melde ihn an Supabase, nicht an Capgo. Wenn die verwundbare Logik, SQL, RPC, RLS-Policy, Edge Function oder Konfiguration von Capgo erstellt oder gewählt wurde und wir sie in unserem Projekt beheben können, ist sie im Scope – auch wenn Supabase den Endpoint bereitstellt. Bei Findings zum Supabase-Verhalten selbst füge bitte einen reproduzierbaren Fall und die exakte Supabase-Einstellung oder Konfigurationsänderung bei, die das Problem in einem wie unserem konfigurierten Projekt verhindert.

Beispiele

Bekannte Einschränkungen von Supabase Auth (bereits gemeldet)

Einige Befunde werden wiederholt gemeldet und sind auf Standardwerte von Supabase Auth oder das Plattformverhalten zurückzuführen, nicht auf Capgo code. Wir prüfen diese nur, wenn sie in einem geteilten Supabase-Demoprojekt reproduzierbar sind, das wie unseres konfiguriert ist, und wenn die Behebung eine Konfigurationsänderung auf Supabase-Seite erfordert, die keine Änderung der Capgo-Sicherheitsregeln erfordert. Wenn die Behebung eine Änderung von Capgo-eigenem SQL, RPCs, RLS-Richtlinien, Funktionen oder App-Logik erfordert, melden Sie es uns, da dies im Geltungsbereich liegt.

• Stellen Sie einen reproduzierbaren Fall bereit und identifizieren Sie die genaue Behebung: entweder die Supabase-Einstellung/Konfigurationsänderung, die ein Supabase-Verhaltungsproblem löst, oder das Capgo-eigene code/Konfigurationsobjekt, das geändert werden muss.
• Das Verhalten der E-Mail-Verifizierung soll den Einstellungen Ihres Supabase Auth-Projekts folgen (z. B. ob die E-Mail-Bestätigung deaktiviert ist und eine capture-basierte Authentifizierung verwendet wird).
• Passwortaktualisierungs- und Kontowiederherstellungsabläufe erfordern möglicherweise nicht immer die erneute Eingabe des alten Passworts oder eine erneute Verifizierung, wenn Supabase Auth so konfiguriert ist.
• Wenn das Problem in dieser Liste steht, Sie aber eine konkrete Behebung auf Supabase-Seite im bereitgestellten Projekt oder einen konkreten Capgo-eigenen Sicherheitsmangel nachweisen können, können wir es als im Geltungsbereich liegend betrachten.

Für Fragen zu unserem Bug-Bounty-Programm wenden Sie sich bitte über unsere GitHub Security Advisories an uns.