Saltare al contenuto principale
Capgo logo

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.

Sorgente Aperta Code

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

Organizzazione GitHub: github.com/Cap-go

Capgo Backend & Landing

Repository principale Capgo che include servizi backend e sito web di presentazione

Visualizza Repository Segnala Problema di Sicurezza

Capacitor Updater Plugin

Il plugin Capacitor di base che gestisce gli aggiornamenti in rete su dispositivi mobili

Visualizza Repository Segnalazione Problema di Sicurezza

Requisiti per Relazioni Valide

Per qualificarsi per il programma Bug Bounty, la tua relazione deve soddisfare TUTTI i seguenti requisiti:

  • Devi identificare il file e il numero di riga esatto nel nostro repository GitHub dove esiste la vulnerabilità
  • La tua relazione deve essere inviata 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 l'issue

Importante: Se non puoi fornire la riga esatta di code in GitHub dove il problema esiste, la tua relazione non sarà eleggibile per il programma Bug Bounty. Le relazioni devono essere inviate attraverso GitHub Advisory di Sicurezza solo. I pagamenti sono gestiti da Algora.io; per favore crea un account lì affinché possiamo pagarti direttamente sul platform.

Tempo di Risposta e Rispetto

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

  • Rispondiamo a rapporti di sicurezza e 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.
  • Sono accettati solo i rapporti in ambito di questo programma di bug bounty; qualsiasi altra cosa potrebbe essere bloccata.
  • Non chiedere aggiornamenti sullo stato come "avete controllato?" o domande simili. Una volta che confermiamo di aver ricevuto il tuo rapporto, basta così. Dopo di che, ci sono ancora molte cose da fare, e preparare una richiesta di pull può richiedere diversi giorni.

Importante: Capgo è una piccola azienda bootstrappata, quindi gli importi della nostra borsa sono inferiori rispetto ai programmi delle grandi aziende. I rapporti senza un chiaro percorso di exploit sono pagati fino a $30 massimo. Gli exploit con un impatto reale e riproducibile su Capgo sono pagati fino a $300 massimo. I pagamenti sono emessi solo dopo che abbiamo identificato l'errore, lo abbiamo corretto, abbiamo aperto una richiesta di pull e tu hai verificato dopo la release che la correzione funziona per te. Questo processo solitamente richiede tra i 20 e i 30 giorni. Per favore, non inviare messaggi come "per ricevere il pagamento"; il pagamento avviene solo quando la release è live e hai testato e validato la correzione.

Come Segnalare

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

Fuori Scopo

  • I report senza riferimenti di riga esatti code in GitHub
  • I report non inviati attraverso GitHub Security Advisory
  • Vulnerabilità teoriche senza prova di concetto
  • Bug nei piattaforme, dipendenze o servizi terzi che Capgo non può risolvere direttamente (segnalali in alto, ad esempio a Supabase).
  • Tentativi di ingegneria sociale o di phishing
  • Attacchi di servizio
  • Report di SSRF o DNS spoofing contro webhook o anteprima del sito web. Queste funzionalità eseguono infrastruttura serverless e non possono essere utilizzate per raggiungere l'infrastruttura Capgo privata, quindi non sono esploitabili nel nostro ambiente.

Supabase e Servizi Terzi

Se la causa radice è un bug della piattaforma o del servizio Supabase, segnala il problema a Supabase, non a Capgo. Se la logica vulnerabile, SQL, RPC, politica di accesso ai dati, Funzione di Edge o configurazione è stata creata o scelta da Capgo e possiamo risolverla nel nostro progetto, è in ambito anche quando Supabase gestisce l'endpoint. Per i ritrovamenti sulla comportamento di Supabase stesso, includi un caso riproducibile e la configurazione o il cambio di impostazione Supabase che lo prevenirebbe in un progetto configurato come il nostro.

Esempi

Noto qui

  • Un bug, un'interruzione o un comportamento della piattaforma Supabase che solo Supabase può risolvere
  • Un problema che non è possibile riprodurre
  • A claim that blames Capgo for Supabase behavior without showing a Capgo-controlled fix or the exact Supabase setting/config change

Noto qui

  • Una configurazione errata di Supabase controllata da Capgo che possiamo risolvere nelle impostazioni del nostro progetto (con passaggi)
  • Un problema di SQL, RPC, RLS, funzione o integrazione di proprietà di Capgo che causa un utilizzo non sicuro di Supabase
  • Un problema riproducibile nel progetto, nella schema o nelle politiche di Supabase di Capgo, anche se è esposto attraverso un endpoint di Supabase

Limitazioni note di Autenticazione di Supabase (Già segnalate)

Alcuni ritrovamenti vengono segnalati ripetutamente e sono causati dalle impostazioni predefinite di Autenticazione di Supabase o dal comportamento della piattaforma piuttosto che da Capgo code. Li esaminiamo solo quando possono essere riprodotti in un progetto demo di Supabase condiviso configurato come il nostro e quando la correzione è un cambiamento di configurazione di Supabase che non richiede modificare le regole di sicurezza di Capgo. Se la correzione richiede modificare SQL, RPC, politiche di RLS, funzioni o logica di applicazione di proprietà di Capgo, segnalarlo a noi perché è in ambito.

  • Inviare un caso riproducibile e identificare la correzione esatta: o il cambiamento di impostazione/configurazione di Supabase che risolve un problema di comportamento di Supabase, o l'oggetto Capgo-controllato code/config che deve cambiare.
  • Il comportamento della verifica dell'e-mail è previsto che segua le impostazioni del progetto di Autenticazione di Supabase (ad esempio, se la conferma dell'e-mail è disabilitata e si utilizza l'autenticazione basata sulle captura).
  • Aggiornamento della password e flussi di ripristino dell'account potrebbero non richiedere sempre la riconferma della vecchia password o la riconferma se Supabase Auth è configurato in questo modo.
  • Se il problema è in questa lista ma puoi mostrare una soluzione concreta da parte di Supabase nel progetto fornito o un difetto di sicurezza concreto di proprietà di Capgo, possiamo considerarlo nell'ambito.

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