Programa de recompensa por fallos
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ódigo fuente.
Fuente Abierta Code
Cada repositorio en la organización Capgo es de código abierto. Puede revisar, auditar y contribuir a nuestros code.
Organización GitHub github.com/Cap-go
Capgo Backend & Landing
Repositorio principal de Capgo que incluye servicios de backend y sitio web de aterrizaje
Plugin de Actualizador de Capacitor
El plugin de Capacitor central que maneja actualizaciones sobre la red en dispositivos móviles
Requisitos para Informes Validos
Para calificar para el programa de Bug Bounty, su informe debe cumplir con TODOS los siguientes requisitos:
- Debes identificar el archivo y el número de línea exactos 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
Importante: Si no puedes proporcionar la línea exacta de code en GitHub donde existe el problema, su informe no será elegible para el programa de Bug Bounty. Los informes deben ser presentados a través de GitHub Security Advisory solo. Los pagos se manejan a través de Algora.io; por favor, crea una cuenta allí para que podamos pagaros directamente en la plataforma.
Tiempo de Respuesta y Respeto
Somos amigables y pagamos por informes válidos, pero no podemos trabajar con personas que no respetan nuestro tiempo. Por favor, mantén la comunicación calmada y sigue este programa.
- Respondemos a informes de seguridad y brechas dentro de 24-72 horas.
- No nos spamifiquen. 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.
- Solo se aceptan informes en el ámbito de este programa de recompensas por errores; cualquier otra cosa puede ser bloqueada.
- No pregunte por actualizaciones de estado como "¿has comprobado?" o preguntas similares. Una vez que confirmemos que hemos recibido 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.
Importante: Capgo es una empresa pequeña y autónoma, por lo que nuestros montos de recompensa son inferiores a los programas de grandes empresas. Se pagan informes sin un claro camino de explotación hasta $30 máximo. Explosiones con un impacto real y reproducible en Capgo se pagan hasta $300 máximo. Aceptamos y revisamos informes de seguridad para los plugins de Capgo, pero las recompensas pagadas por los plugins de code están limitadas a @capgo/capacitor-actualizador. Los demás plugins de Capgo son gratuitos y no forman parte de nuestra oferta de producto pagada, por lo que los informes sobre ellos se revisan pero no se pagan. Los pagos se emiten solo después de que hayamos identificado el problema, lo hemos corregido, hemos abierto una solicitud de extracción y usted ha verificado después de la publicación que la corrección funciona para usted. Este proceso suele tardar entre 20 y 30 días. No envíe mensajes como "para obtener pagos"; los pagos solo se realizan una vez que la publicación esté disponible y haya probado y validado la corrección.
Cómo Informar
- Navegue hasta el repositorio relevante en GitHub
- Haga clic en la pestaña "Seguridad"
- Haga clic en "Informar una vulnerabilidad" para crear un nuevo informe de seguridad
- Incluya el camino de archivo exacto y el número de línea(s) donde existe la vulnerabilidad.
- Proporcione pasos detallados para reproducir el problema y explique el impacto de seguridad.
Fuera de alcance
- Informes sin referencias de línea exactas en code y GitHub
- Informes no presentados a través de GitHub Security Advisory
- Vulnerabilidades teóricas sin prueba de concepto
- Bugs en plataformas, dependencias o servicios de terceros que Capgo no puede solucionar directamente (informe a los proveedores, por ejemplo a Supabase).
- Intentos de ingeniería social o de phishing
- Ataques de denegación de servicio
- Informes de SSRF o DNS spoofing contra webhooks o vista previa de sitios web. Estas características se ejecutan en infraestructura sin servidor y no pueden usarse para acceder a la infraestructura privada de Capgo, por lo que no son explotables en nuestro entorno.
- Configuración de la aplicación o proyecto de propiedad del usuario code que Capgo no posee, envía, ni controla, incluyendo archivos como capacitor.config.ts, config.capacitor.ts, código fuente de la aplicación code, y ajustes específicos del entorno.
- Acceso a archivos de paquete Capgo o prueba de que los archivos de paquete pueden descargarse. Los archivos de 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 o problema de un servicio de la plataforma Supabase, informe el problema a Supabase, no 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 final. 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
No válido aquí
- Un error o comportamiento de la plataforma Supabase que solo Supabase puede arreglar
- Un hallazgo que no se puede reproducir
- A claim that blames Capgo for Supabase behavior without showing a Capgo-controlled fix or the exact Supabase setting/config change
Válido aquí
- Una configuración de Supabase mal configurada controlada por Capgo que podemos arreglar en las configuraciones de nuestro proyecto (con pasos)
- Un problema de SQL, RPC, RLS, función o integración propiedad de Capgo que causa un uso inseguro de Supabase
- Un problema reproducible en el proyecto, esquema o políticas de Supabase propiedad de Capgo, incluso si se expone a través de un punto final de Supabase
Limitaciones de Autenticación de Supabase (Ya Informadas)
Algunos hallazgos se informan repetidamente y están causados por Supabase Auth por defecto o comportamiento de la plataforma en lugar de Capgo code. Revisamos estos solo cuando pueden reproducirse en un proyecto de demostración compartido de Supabase configurado como el nuestro y cuando la solución es un cambio de configuración de Supabase que no requiere cambiar Capgo reglas de seguridad. Si el cambio requiere cambiar Capgo-propiedad SQL, RPCs, políticas de RLS, funciones o lógica de la aplicación, informe sobre ello porque eso está en el alcance.
- Proporcione un caso reproducible e identifique la solución exacta: ya sea el ajuste/configuración de Supabase que resuelve un problema de comportamiento de Supabase, o el objeto de configuración Capgo-propiedad code que debe cambiar.
- El comportamiento de verificación de correo electrónico se espera que siga los ajustes del proyecto de autenticación de Supabase (por ejemplo, si la confirmación de correo electrónico está deshabilitada y se utiliza la autenticación basada en captura).
- Los flujos de actualización de contraseña y recuperación de cuenta pueden no requerir siempre la reingreso o reverificación de la contraseña antigua si Supabase Auth está configurado de esa manera.
- Si el problema está en esta lista pero puede mostrar una solución concreta de Supabase en el proyecto proporcionado o un defecto de seguridad Capgo-propiedad, podemos considerarlo en el alcance.
Para preguntas sobre nuestro programa de recompensas de errores, por favor, contacte con nosotros a través de nuestros GitHub Consejos de Seguridad.