Programma di ricompensa per bug

Capgo si impegna per la sicurezza e la trasparenza. Tutti i nostri code sono open source, e accogliamo i ricercatori di sicurezza per aiutarci a identificare le vulnerabilità nel nostro codice.

Open Source Code

Ogni repository nell'organizzazione Capgo è open source. Puoi esaminare, auditare e contribuire ai nostri code.

GitHub Organizzazione: github.com/Cap-go

Requisiti per Relazioni Valide

Devi identificare l'esatto file e il numero di riga del nostro __CAPGO_KEEP_0__ repository dove esiste la vulnerabilità

• Devi identificare con precisione il file e il numero di riga nel nostro repository GitHub in cui esiste la vulnerabilità
• Il tuo rapporto deve essere inviato attraverso GitHub Advisory di Sicurezza sul repository pertinente
• Devi includere una descrizione chiara della vulnerabilità e del suo impatto potenziale
• Devi fornire passaggi riproducibili per dimostrare il problema

Tempo di Risposta e Rispetto

Siamo amichevoli e paghiamo per i rapporti validi, ma non possiamo lavorare con persone che non rispettano il nostro tempo. Per favore mantieni la comunicazione calma e segui questo programma.

• Rispondiamo ai rapporti di sicurezza e alle violazioni entro 24-72 ore.
• Non ci spammare. Più di tre email in un solo giorno è considerato spam e verrà bloccato.
• Non paghiamo per i rapporti che ignorano queste regole o sono spam.
• Solo i rapporti in-scope che seguono questo programma Bug Bounty sono accettati; qualsiasi altra cosa potrebbe essere bloccata.
• Non chiedere aggiornamenti sullo stato come "hai controllato?" o domande simili. Una volta che confermiamo di aver ricevuto il tuo rapporto, è sufficiente. Dopo di che, ci sono ancora lavori significativi da fare, e preparare una richiesta di pull può richiedere diversi giorni.

Come segnalare

1. Naviga al repository relativo su GitHub
2. Clicca sulla scheda "Security"
3. Clicca "Segnala una vulnerabilità" per creare un nuovo avviso di sicurezza
4. Includi il percorso file esatto e il numero di riga (le) dove la vulnerabilità esiste
5. Descrivi i passaggi dettagliati per riprodurre il problema e spiega l'impatto di sicurezza

Fuori Scopo

• I rapporti senza riferimenti di riga esatti di code in GitHub
• I rapporti non inviati attraverso GitHub Security Advisory
• Il vulnerabilità teorici senza un concetto di prova
• Bachi in piattaforme, dipendenze o servizi di terze parti che Capgo non può risolvere direttamente (segnalare quelli upstream, ad esempio a Supabase).
• Prove di ingegneria sociale o tentativi di phishing
• Attacchi di servizio di negazione
• SSRF o DNS spoofing sui report per webhook o anteprima del sito. Queste funzionalità eseguono infrastrutture serverless e non possono essere utilizzate per raggiungere l'infrastruttura privata Capgo, quindi non sono esploitabili nel nostro ambiente.
• Configurazioni di progetto o applicazione code di proprietà dell'utente che Capgo non possiede, distribuisce o controlla, compresi file come capacitor.config.ts, config.capacitor.ts, sorgenti dell'applicazione code e impostazioni specifiche per l'ambiente.
• Accesso ai file del pacchetto Capgo o prove che i file del pacchetto possono essere scaricati. I file del pacchetto sono risorse web pubbliche, gli utenti sono informati di questo e l'accesso a loro non è considerato una violazione dei dati.
• 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.
• L'etichettatura di crittografia da parte dell'uploader o dell'interfaccia utente per bundle serviti tramite external_url non è una vulnerabilità Capgo (la crittografia dei bundle ospitati esternamente è fuori dal controllo di Capgo).

Supabase e Servizi Terzi

Se la causa radice è un bug del piattaforma o servizio Supabase, segnalarlo a Supabase, non Capgo. Se la logica vulnerabile, SQL, RPC, politica RLS, Funzione Edge o configurazione è stata creata o scelta da Capgo e possiamo risolverlo nel nostro progetto, è in ambito anche quando Supabase serve l'endpoint. Per i ritrovamenti sulla comportamento Supabase stesso, includere un caso riproducibile e l'esatto impostazione Supabase o modifica di configurazione che lo prevenirebbe in un progetto configurato come il nostro.

Esempi

Limitazioni note di Autenticazione Supabase (Già segnalate)

Alcuni ritrovamenti vengono segnalati ripetutamente e sono causati dalle impostazioni di autenticazione Supabase o dal comportamento della piattaforma piuttosto che da Capgo code. Rivediamo questi solo quando possono essere riprodotti in un progetto demo Supabase condiviso configurato come il nostro e quando la correzione è un cambiamento di configurazione Supabase che non richiede modifiche alle Capgo regole di sicurezza. Se la correzione richiede modifiche ai Capgo SQL, RPC, politiche RLS, funzioni o logica dell'app, segnalarlo a noi perché è in ambito.

• Fornisci un caso riproducibile e identifica la correzione esatta: o il cambiamento di impostazione/configurazione Supabase che risolve un problema di comportamento Supabase, o l'oggetto Capgo-posseduto code/config che deve cambiare.
• Il comportamento della verifica email deve seguire le impostazioni del tuo progetto di autenticazione Supabase (ad esempio, se la conferma via email è disabilitata e viene utilizzata l'autenticazione basata sulla cattura).
• Aggiornamento della password e flussi di ripristino dell'account potrebbero non richiedere sempre la riconferma dell'antica password o la riconferma se Supabase Auth è configurato in questo modo.
• Se l'issue è in questa lista ma puoi mostrare una correzione concreta Supabase-side nel progetto fornito o una difesa di sicurezza concreta Capgo-posseduta, possiamo considerarlo in ambito.

Per le domande sul nostro programma Bug Bounty, per favore contattaci attraverso le nostre GitHub Security Advisories.