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.

Code de código abierto

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

Organización de 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 de GitHub donde existe la vulnerabilidad
• Su informe debe ser presentado a través de GitHub Advisory de Seguridad en el repositorio relevante.
• Deben incluir una descripción clara de la vulnerabilidad y su impacto potencial.
• Deben 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, mantenga la comunicación calmada y siga este programa.

• Respondemos a los 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 por informes que ignoren estas reglas o sean spam.
• Sólo se aceptan informes en el alcance de este programa de Bug Bounty; cualquier otra cosa puede ser bloqueada.
• No le pidan 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 mucho trabajo que hacer, y preparar una solicitud de extracción puede llevar varios días.

Cómo Informar

1. Navegue a la repositorio relevante en GitHub
2. Haga clic en la pestaña "Seguridad"
3. Haga clic en "Informar una vulnerabilidad" para crear un nuevo aviso de seguridad
4. Incluya el camino de archivo exacto y el número de línea(s) donde existe la vulnerabilidad.
5. Haga clic en "Informar una vulnerabilidad" para crear un nuevo asesoramiento de seguridad

Fuera del alcance

• Informes sin referencias de línea exactas code en GitHub.
• Informes no presentados a través de GitHub de Seguridad
• Vulnerabilidades teóricas sin prueba de concepto
• Bugs en plataformas, dependencias o servicios de terceros que Capgo no puede solucionar directamente (informe esos problemas en la fuente, 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 sitios web. Estas características se ejecutan en infraestructura sin servidor y no pueden usarse para alcanzar la infraestructura privada de Capgo, por lo que no son explotables en nuestro entorno.
• User-owned application code or project configuration that Capgo does not own, ship, or control, including files such as capacitor.config.ts, config.capacitor.ts, app source code, and environment-specific settings.
• Acceso a archivos de paquete de Capgo o prueba de que los archivos de paquete se pueden descargar. 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.
• No se consideran vulnerabilidades los puntos finales de plugin/API de Capgo no autenticados que están diseñados para ser públicos intencionalmente — incluyendo el punto final de actualización/stats que no requiere una clave de API —.
• Uploader or UI incorrectly labeling encryption for bundles served via external_url is not a Capgo vulnerability (encryption of externally hosted bundles is outside Capgo’s control).

Supabase y Servicios de Terceros

Si la causa raíz es un error de plataforma o servicio de 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

Limitaciones conocidas de Supabase Auth (ya informadas)

Algunos hallazgos se informan repetidamente y se deben a los valores por defecto de Supabase Auth o al 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 que no requiere cambiar Capgo las reglas de seguridad. Si la solución requiere cambiar Capgo las reglas de seguridad de SQL, RPCs, políticas RLS, funciones o lógica de la aplicación, informe sobre ello porque eso está en el alcance.

• Proporcione un caso reproducible y 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 Supabase Auth (por ejemplo, si la confirmación de correo electrónico está deshabilitada y se utiliza la autenticación basada en captura).
• Actualización de contraseña y flujos de recuperación de cuenta pueden no requerir siempre la reingreso o re-verificació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 una deficiencia de seguridad Capgo-propiedad, podemos considerarlo en el alcance.

Para preguntas sobre nuestro programa de Bug Bounty, por favor contacta a través de nuestros GitHub Avisos de Seguridad.