Programa de recompensa por vulnerabilidades

Capgo se compromete con la seguridad y la transparencia. Todos nuestros code son de código abierto, y damos la bienvenida a los investigadores de seguridad para ayudarnos a identificar vulnerabilidades en nuestro códigobase.

Code de código abierto

Cada repositorio en la organización Capgo es de código abierto. Puedes revisar, auditar y contribuir a nuestros code.

Organización GitHub: github.com/Cap-go

Requisitos para Informes Válidos

Para calificar para el programa de Bug Bounty, su informe debe cumplir con TODOS los siguientes requisitos:

• Debes identificar con precisión el archivo y el número de línea en nuestro repositorio GitHub donde existe la vulnerabilidad
• Su informe debe ser presentado a través de GitHub Security Advisory en el repositorio relevante
• Debes incluir una descripción clara de la vulnerabilidad y su impacto potencial
• Debes proporcionar pasos reproducibles para demostrar el problema

Tiempo de Respuesta y Respeto

Somos amigables y pagamos por informes válidos, pero no podemos trabajar con personas que no respeten nuestro tiempo. Por favor, mantén la comunicación calmada y sigue este programa.

• Respondemos a los informes de seguridad y brechas dentro de 24-72 horas.
• No nos envíen spam. Más de tres correos electrónicos en un solo día se considera spam y será bloqueado.
• No pagamos informes que ignoren estas reglas o sean spam.
• Sólo se aceptan informes en el alcance de este programa de recompensas de seguridad; cualquier otra cosa puede ser bloqueada.
• No hagan preguntas sobre el estado de actualización, como "¿has revisado?" o similares. Una vez que confirmemos que recibimos su informe, eso es suficiente. Después de eso, todavía hay un trabajo significativo por hacer, y preparar una solicitud de extracción puede llevar varios días.

Cómo Informar

1. Navegue hasta el repositorio relevante en GitHub
2. Haz clic en la pestaña "Seguridad"
3. Haz clic en "Informar una vulnerabilidad" para crear un nuevo consejo de seguridad
4. Incluya el camino de archivo exacto y el número de línea(s) donde existe la vulnerabilidad
5. Proporcione pasos detallados para reproducir el problema y explique el impacto de seguridad

Fuera de alcance

• Reports without exact code line references in GitHub
• Los informes no presentados a través de GitHub Seguimiento de seguridad
• Las vulnerabilidades teóricas sin prueba de concepto
• Los bugs en plataformas, dependencias o servicios de terceros que Capgo no puede arreglar directamente (informe esos upstream, por ejemplo a Supabase)
• Intentos de ingeniería social o phishing
• Ataques de denegación de servicio
• SSRF o informes de suplantación de DNS contra webhooks o vista previa de sitio web. Estas características se ejecutan en infraestructura sin servidor y no se pueden utilizar para acceder a la infraestructura Capgo privada, por lo que no son explotables en nuestro entorno.
• La configuración de la aplicación o proyecto del usuario code o la configuración que Capgo no posee, envía, controla o administra, incluyendo archivos como capacitor.config.ts, config.capacitor.ts, la fuente de la aplicación code y ajustes específicos del entorno.
• El acceso a los archivos del paquete Capgo o la prueba de que los archivos del paquete pueden descargarse. Los archivos del paquete son activos web públicos, los usuarios están informados de esto y el acceso a ellos no se considera una violación de datos.

Supabase y Servicios de Terceros

Si la causa raíz es un error de la plataforma o servicio de Supabase, informe el problema a Supabase, no a Capgo. Si la lógica vulnerable, SQL, RPC, política de RLS, función de Edge o configuración fue creada o elegida por Capgo y podemos arreglarlo en nuestro proyecto, está en el alcance incluso cuando Supabase sirve el punto de conexión. Para hallazgos sobre el comportamiento de Supabase en sí mismo, incluya un caso reproducible y el ajuste de configuración Supabase o el cambio de configuración exacto que lo previene en un proyecto configurado como el nuestro.

Ejemplos

Limitaciones conocidas de Supabase Auth (ya informadas)

Algunos hallazgos se informan repetidamente y están causados por los valores predeterminados de Supabase Auth o el comportamiento de la plataforma en lugar de Capgo code. Revisamos estos solo cuando pueden reproducirse en un proyecto de demostración de Supabase compartido configurado como el nuestro y cuando la solución es un cambio de configuración de Supabase del lado de la plataforma que no requiere cambiar las reglas de seguridad de Capgo. Si el cambio requiere cambiar las reglas de seguridad de SQL, RPCs, políticas de RLS, funciones o lógica de la aplicación de Capgo, informe sobre ello porque eso está en el alcance.

• Proporcione un caso reproducible y identifique la solución exacta: o el cambio de configuración de Supabase que resuelve un problema de comportamiento de Supabase, o el objeto de configuración de Capgo-dueño/code que debe cambiar.
• El comportamiento de verificación de correo electrónico se espera que siga los ajustes del proyecto de Supabase Auth (por ejemplo, si la confirmación de correo electrónico está deshabilitada y se utiliza la autenticación basada en captura).
• Las flujos de actualización de contraseña y recuperación de cuenta pueden no requerir siempre la reingreso de la contraseña antigua o la reverificación si Supabase Auth está configurado de esa manera.
• Si el problema está en esta lista pero puede mostrar una solución concreta de Supabase del lado de la plataforma en el proyecto proporcionado o un defecto de seguridad concreto de Capgo, podemos considerarlo en el alcance.

Para preguntas sobre nuestro programa de Bug Bounty, por favor, contacte con nosotros a través de nuestros GitHub Security Advisories.