Programma Bug Bounty

Capgo è impegnata nella sicurezza e nella trasparenza. Tutto il nostro code è open source, e invitiamo i ricercatori di sicurezza ad aiutarci a identificare vulnerabilità nel nostro codebase.

Code Open Source

Ogni repository nell'organizzazione Capgo è open source. Puoi revisionare, auditare e contribuire al nostro code.

Organizzazione GitHub: github.com/Cap-go

Requisiti per i Report Validi

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

• Devi identificare il file esatto e il numero di riga nel nostro repository GitHub in cui risiede la vulnerabilità
• Il report deve essere inviato tramite la GitHub Security Advisory sul repository pertinente
• Devi includere una descrizione chiara della vulnerabilità e del suo potenziale impatto
• Devi fornire i passaggi per riprodurre il problema e dimostrarlo

Tempi di risposta e rispetto

Siamo disponibili e paghiamo per i report validi, ma non possiamo collaborare con chi non rispetta i nostri tempi. Ti chiediamo di mantenere una comunicazione calma e di seguire le regole di questo programma.

• Rispondiamo ai report di sicurezza e alle violazioni entro 24-72 ore.
• Non inviare spam. Più di tre email in un singolo giorno saranno considerate spam e bloccate.
• Non paghiamo i report che ignorano queste regole o che sono spam.
• Sono accettati solo i report in scope che seguono questo programma bug bounty; qualsiasi altra segnalazione potrebbe essere bloccata.
• Non chiedere aggiornamenti sullo stato, come ad esempio "hai controllato?" o domande simili. Una volta confermata la ricezione della segnalazione, è sufficiente. Dopo tale conferma, resta ancora molto lavoro da fare e la preparazione di una pull request può richiedere diversi giorni.

Come segnalare

1. Vai al repository pertinente su GitHub
2. Clicca sulla tab "Security"
3. Clicca su "Report a vulnerability" per creare un nuovo security advisory
4. Includi il percorso esatto del file e il numero di riga in cui risiede la vulnerabilità
5. Fornisci passaggi dettagliati per riprodurre il problema e spiega l'impatto sulla sicurezza

Fuori Ambito

• Report senza riferimenti esatti alle righe di code in GitHub
• Report non inviati tramite GitHub Security Advisory
• Vulnerabilità teoriche senza una proof of concept
• Bug in piattaforme di terze parti, dipendenze o servizi che Capgo non può risolvere direttamente (segnalali ai provider, ad esempio a Supabase).
• Tentativi di social engineering o phishing
• Attacchi Denial of Service
• Report di SSRF o DNS spoofing contro webhook o anteprime del sito. Queste funzionalità girano su infrastruttura serverless e non possono essere usate per raggiungere l'infrastruttura privata di Capgo, quindi non sono sfruttabili nel nostro ambiente.
• Configurazione di code dell'app o del progetto di proprietà dell'utente che Capgo non possiede, distribuisce o controlla, inclusi file come capacitor.config.ts, config.capacitor.ts, il codice sorgente code e le impostazioni specifiche dell'ambiente.
• Accesso ai file del bundle Capgo o prova che i file del bundle possono essere scaricati. I file del bundle sono asset web pubblici, gli utenti ne sono informati e l'accesso non è considerato una violazione dei dati.
• Endpoint Capgo plugin/API non autenticati che sono intenzionalmente pubblici per design — inclusi channel_self set e gli endpoint update/stats che non richiedono una API key — non sono vulnerabilità. Non segnalarli come tali.
• Un errore di etichettatura della crittografia nell'uploader o nella UI per i bundle serviti via external_url non è una vulnerabilità Capgo (la crittografia dei bundle ospitati esternamente è fuori dal controllo di Capgo).

Supabase e servizi di terze parti

Se la causa principale è un bug della piattaforma o di un servizio Supabase, segnalalo a Supabase e non a Capgo. Se la logica vulnerabile, SQL, RPC, policy RLS, Edge Function o la configurazione sono stati creati o scelti da Capgo e possiamo risolverli nel nostro progetto, rientrano nel perimetro anche se l'endpoint è servito da Supabase. Per segnalazioni sul comportamento di Supabase, includi un caso riproducibile e l'esatta impostazione o modifica di config di Supabase che lo causa in un progetto configurato come il nostro.

Esempi

Limitazioni note di Supabase Auth (già segnalate)

Alcune vulnerabilità vengono segnalate ripetutamente e sono causate dai default di Supabase Auth o dal comportamento della piattaforma, piuttosto che da Capgo code. Le prendiamo in esame solo se riproducibili in un progetto demo Supabase condiviso e configurato come il nostro, e se la soluzione consiste in una modifica di configurazione lato Supabase che non richieda variazioni alle regole di sicurezza Capgo. Se la fix richiede modifiche a SQL, RPC, policy RLS, funzioni o logica dell'app di proprietà di Capgo, segnalacela perché rientra nel perimetro.

• Fornisci un caso riproducibile e identifica la fix esatta: o la modifica alle impostazioni/configurazione di Supabase che risolve il problema, o l'oggetto code/config di proprietà di Capgo che deve essere modificato.
• Il comportamento della verifica email segue le impostazioni del tuo progetto Supabase Auth (ad esempio, se la conferma email è disabilitata o se viene usato l'auth basato su capture).
• I flussi di aggiornamento password e recupero account potrebbero non richiedere sempre l'inserimento della vecchia password o una nuova verifica se Supabase Auth è configurato in tal senso.
• Se il problema è in questo elenco ma riesci a dimostrare una fix concreta lato Supabase nel progetto fornito o un difetto di sicurezza concreto di proprietà di Capgo, potremo considerarlo nel perimetro.

Per domande sul nostro programma Bug Bounty, contatta il team tramite le GitHub Security Advisories.