Saltare al contenuto principale
Capgo logo

Programma di ricompensa per i 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

Tutti i repository dell'organizzazione Capgo sono open source. Puoi esaminare, auditare e contribuire ai nostri code.

Organizzazione GitHub: github.com/Cap-go

Sviluppo Backend & Landing di Capgo

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

Visualizza Repository Segnala Problema di Sicurezza

Plugin di Aggiornamento di Capacitor

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

Visualizza Repository Segnala Problema di Sicurezza

Requisiti per Rapporti Validi

Per partecipare al programma Bug Bounty, il tuo rapporto deve soddisfare TUTTI i seguenti requisiti:

  • Devi identificare il file e il numero di riga esatto nel nostro repository GitHub dove esiste la vulnerabilità
  • Il tuo rapporto deve essere inviato attraverso GitHub Security Advisory 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 esiste il problema, il tuo rapporto non sarà eleggibile per il programma Bug Bounty. I rapporti devono essere inviati attraverso GitHub Security Advisory solo. I pagamenti sono gestiti da Algora.io; per favore crea un account lì affinché possiamo pagarti direttamente sulla piattaforma.

Tempo di Risposta e Rispetto

Siamo amichevoli e paghiamo per 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 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 i nostri importi di borsa sono inferiori rispetto ai programmi delle grandi aziende. I rapporti senza un chiaro percorso di sfruttamento sono pagati fino a $30 massimo. Gli sfruttamenti con un impatto reale e riproducibile su Capgo sono pagati fino a $300 massimo. Accettiamo e revisioniamo i rapporti di sicurezza per i plugin Capgo, ma i bounties pagati per i plugin code sono limitati a @capgo/capacitor-aggiornatore. Gli altri plugin Capgo sono gratuiti e non fanno parte della nostra offerta di prodotto pagata, quindi i rapporti per loro vengono revisionati ma non sono pagati. I pagamenti vengono emessi solo dopo che abbiamo identificato l'errore, lo abbiamo corretto, abbiamo aperto una richiesta di pull e tu hai verificato dopo la rilascio 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 il rilascio è live e hai testato e validato la correzione.

Come segnalare un problema

  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. Includere il percorso file esatto e il numero di riga/i dove esiste la vulnerabilità
  5. Fornire passaggi dettagliati per riprodurre l'errore e spiegare l'impatto di sicurezza

Fuori Scopo

  • I report senza riferimenti di riga esatti in code in GitHub
  • I report non sottoposti attraverso GitHub Security Advisory
  • Vulnerabilità teoriche senza prova di concetto
  • Bug in piattaforme, dipendenze o servizi di terze parti che Capgo non può risolvere direttamente (riferirli ad esempio a Supabase)
  • Tentativi di ingegneria sociale o di phishing
  • Attacchi di servizio
  • Report di SSRF o spoofing DNS 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.
  • Configurazione dell'applicazione code o del progetto di proprietà dell'utente che Capgo non possiede, distribuisce o controlla, inclusi 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 la prova che i file del pacchetto possono essere scaricati. I file del pacchetto sono asset web pubblici, gli utenti sono informati di questo e l'accesso a loro non è considerato una violazione dei dati.

E Supabase e Servizi Terzi

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

Esempi

Non valido qui

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

Valido qui

  • Una configurazione di Supabase non corretta 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 di Supabase non sicuro
  • Un problema riproducibile nel progetto, nella schema o nelle politiche di Supabase di Capgo, anche se è esposto attraverso un endpoint di Supabase

Limitazioni di Autenticazione di Supabase (Già Segnalate)

Alcune scoperte vengono riportate ripetutamente e sono causate da impostazioni di autenticazione Supabase o comportamento della piattaforma piuttosto che Capgo code. Rivediamo queste solo quando possono essere riprodotte 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 a SQL, RPC, politiche RLS, funzioni o logica dell'app di Capgo, 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-owned code/config che deve cambiare.
  • Il comportamento della verifica dell'indirizzo e-mail è previsto per seguire le impostazioni del progetto di autenticazione Supabase (ad esempio, se la conferma dell'indirizzo e-mail è disabilitata e si utilizza l'autenticazione basata sulla cattura).
  • I flussi di aggiornamento della password e di recupero dell'account possono non richiedere sempre la rientro della vecchia password o la riconferma se l'autenticazione Supabase è configurata in questo modo.
  • Se il problema è in questa lista ma puoi mostrare una correzione concreta da parte di Supabase o un difetto di sicurezza Capgo-owned, possiamo considerarlo in ambito.

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