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 codicebase.

Open Source Code

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

GitHub Organization: github.com/Cap-go

Capgo Backend & Landing

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

Visualizza Repository Segnala Problema di Sicurezza

Capacitor Plugin di Aggiornamento

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

Visualizza Repository Segnalare un problema di sicurezza

Requisiti per le segnalazioni valide

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

Devi identificare esattamente il file e il numero di riga del nostro repository GitHub dove esiste la vulnerabilità
La tua segnalazione 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 segnalazione non sarà eleggibile per il programma Bug Bounty. Le segnalazioni 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 sulla piattaforma.

Tempo di risposta e rispetto

Siamo amichevoli e paghiamo per le segnalazioni 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-scope che seguono questo programma di bug bounty; qualsiasi altra cosa può 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 a quelli dei 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. Accettiamo e revisioniamo i rapporti di sicurezza per i plugin Capgo, ma le borse pagate per i plugin code sono limitate a @capgo/capacitor-aggiornatore. Altri plugin Capgo sono gratuiti e non fanno parte della nostra offerta di prodotto pagata, quindi i rapporti per loro vengono revisionati ma non pagati. I pagamenti vengono emessi solo dopo che abbiamo identificato il problema, lo abbiamo risolto, abbiamo aperto una richiesta di pull e tu hai verificato dopo la release che il fix 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 una volta che la release è live e hai testato e validato il fix.

Come segnalare un bug

Naviga al repository relativo su GitHub
Clicca sul pulsante "Security"
Clicca su "Segnalazione di vulnerabilità" per creare un nuovo avviso di sicurezza
Includi il percorso file esatto e il numero di riga (o righe) dove la vulnerabilità esiste
Fornisci passaggi dettagliati per riprodurre il problema e spiega l'impatto sulla sicurezza

Fuori Scopo

Reports without exact code line references in GitHub
Segnalazioni non inviate attraverso GitHub Security Advisory
Vulnerabilità teoriche senza prova di concetto
Bug nei piattaforme, dipendenze o servizi terzi che Capgo non può risolvere direttamente (segnaletica quelli upstream, ad esempio a Supabase)
Tentativi di ingegneria sociale o phishing
Attacchi di servizio
Segnalazioni di SSRF o DNS spoofing contro webhook o anteprima del sito web. Queste funzionalità eseguono l'infrastruttura serverless e non possono essere utilizzate per raggiungere l'infrastruttura Capgo privata, quindi non sono eseguibili nel nostro ambiente.
Un'applicazione o un progetto di configurazione code di proprietà dell'utente o che Capgo non possiede, distribuisce, controlla, inclusi file come capacitor.config.ts, config.capacitor.ts, codice sorgente code e impostazioni specifiche dell'ambiente.
Accesso ai file del pacchetto Capgo o prova che i file del pacchetto possono essere scaricati. I file del pacchetto sono risorse web pubbliche, gli utenti ne sono informati e l'accesso a esse non è considerato una violazione dei dati.

Supabase e Servizi Terzi

Se la causa radice è un bug della piattaforma o di un servizio Supabase, segnalarlo a Supabase, non a Capgo. Se la logica vulnerabile, SQL, RPC, politica RLS, Funzione di Edge o la configurazione è stata creata o scelta da Capgo e possiamo risolverla nel nostro progetto, è in ambito anche quando Supabase serve l'endpoint. Per le informazioni relative al comportamento di Supabase stesso, includere un caso riproducibile e le impostazioni o il cambiamento di configurazione Supabase esatto che lo prevenisse in un progetto configurato come il nostro.

Esempi

Non valido qui

Un bug, un'interruzione o un comportamento della piattaforma Supabase che solo Supabase può risolvere
Un ritrovamento che non si può riprodurre
Una pretesa che incolpa Capgo per il comportamento di Supabase senza mostrare una correzione Capgo-controllata o le impostazioni o il cambiamento di configurazione Supabase esatto

Valido qui

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

Limitazioni note di Supabase Auth (già segnalate)

Alcune scoperte sono segnalate ripetutamente e sono causate dalle impostazioni predefinite di Supabase Auth o dal comportamento della piattaforma piuttosto che da 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 regole di sicurezza di Capgo. Se il cambiamento richiede modifiche ai SQL, RPC, politiche RLS, funzioni o logica dell'app di Capgo, segnalarlo a noi perché è in ambito

Fornire un caso riproducibile e identificare 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 dell'e-mail è atteso che segua le impostazioni del progetto Supabase Auth (ad esempio, se la conferma dell'e-mail è disabilitata e si utilizza l'autenticazione basata sulla cattura)
Il flusso di aggiornamento della password e di recupero dell'account non richiede sempre la riconferma dell'antico 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 difetto di sicurezza concreto Capgo-posseduto, possiamo considerarlo in ambito

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