Saltar al contenido principal
Capgo logo

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ódigo.

Código abierto Code

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

Capgo Backend & Landing

Repositorio principal Capgo incluyendo servicios de backend y sitio web de aterrizaje

Ver Repositorio Informar una vulnerabilidad de seguridad

Capacitor Updater Plugin

El plugin de Capacitor principal que maneja actualizaciones sobre la marcha en dispositivos móviles

[View Repository] [Reportar un problema de seguridad]

[Requisitos para informes válidos]

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

  • We respond to security reports and breaches within 24-72 hours.
  • No envíe spam. Más de tres correos electrónicos en un solo día se considera spam y será bloqueado.
  • No pagamos por informes que ignoran estas reglas o son spam.
  • Sólo se aceptan informes en el alcance de este programa de recompensas de bug; cualquier otra cosa puede ser bloqueada.
  • No pregunte por actualizaciones de estado, como "¿has revisado?" o preguntas 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.

Importante: Capgo es una empresa pequeña y autónoma, por lo que nuestros montos de recompensa son más bajos que los programas de grandes empresas. Los informes sin un camino claro de explotación se pagan hasta un máximo de $30. Las explotaciones con un impacto real y reproducible en Capgo se pagan hasta un máximo de $300. 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 liberación que la corrección funciona para usted. Este proceso suele tardar entre 20 y 30 días. Por favor, no envíe mensajes como "para obtener pagado"; el pago solo ocurre una vez que la liberación esté disponible y usted haya probado y validado la corrección.

Cómo Informar

  1. Navegue hasta el repositorio relevante en GitHub
  2. Haga clic en la pestaña "Seguridad"
  3. Haga clic en "Reportar 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. Proporciona pasos detallados para reproducir el problema y explica el impacto de seguridad

Fuera de alcance

  • Informes sin referencias de línea exactas en code en 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 arreglar directamente (informa 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 se pueden utilizar para acceder a la infraestructura privada de Capgo, por lo que no son explotables en nuestro entorno.

Supabase y Servicios de Terceros

Si la causa raíz es un bug de la plataforma o servicio de Supabase, informa a Supabase, no a Capgo. Si la lógica vulnerable, SQL, RPC, política de acceso a datos, función de borde 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í, incluye un caso reproducible y el ajuste de configuración Supabase o el cambio de configuración que lo previene en un proyecto configurado como el nuestro.

Ejemplos

Not válido aquí

  • Un error de la plataforma Supabase que solo Supabase puede solucionar
  • Un problema 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í

  • A Capgo-controlled Supabase misconfiguration we can fix in our project settings (with steps)
  • Un problema de seguridad causado por una configuración de Supabase insegura propiedad de Capgo
  • Un problema reproducible en el proyecto de Supabase de Capgo, esquema o políticas, incluso si se expone a través de un punto final de Supabase

Limitaciones de autenticación de Supabase conocidas (ya reportadas)

Algunos hallazgos se reportan repetidamente y están causados por los valores por defecto de autenticación de Supabase o el comportamiento de la plataforma en lugar de Capgo code. Revisamos estos solo cuando se pueden reproducir 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 que no requiere cambiar las reglas de seguridad de Capgo. Si la solución requiere cambiar la propiedad de Capgo de SQL, RPCs, políticas de RLS, funciones o lógica de la aplicación, informe sobre ello porque eso está en el alcance.

  • Provide a reproducible case and identify the exact fix: either the Supabase setting/config change that resolves a Supabase behavior issue, or the Capgo-owned code/config object that must change.
  • El comportamiento de verificación de correo electrónico se espera que siga los ajustes de 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 no siempre requieren 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 puedes mostrar una solución concreta de Supabase en el proyecto proporcionado o un defecto de seguridad propiedad de Capgo, podemos considerarlo en el alcance.

Para preguntas sobre nuestro programa de Bug Bounty, por favor, comunícate a través de nuestros GitHub Security Advisories.